Re: Language translation proposal

[Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>]

Ian Bicking <ianb@colorstudy.com> writes:

> On Sat, Aug 12, 2000 at 08:33:52AM +0200, Mikael Djurfeldt wrote:
> > ** File extension
> > 
> > Guile maintains an alist mapping filename extensions to languages.
> > Each entry has the form:
> > 
> >   (REGEXP . LANGNAME)
> > 
> > where REGEXP is a string and LANGNAME a symbol or a list of symbols.
> > 
> > The alist can be accessed using `language-alist' which is exported
> > by the module `(core config)':
> > 
> >   (language-alist)			--> current alist
> >   (language-alist ALIST) 		sets the alist to ALIST
> >   (language-alist ALIST :prepend)	prepends ALIST onto the current list
> >   (language-alist ALIST :append)	appends ALIST after current list
> > 
> > The `load' command will match filenames against this alist and choose
> > the translator to use accordingly.
> 
> It is unclear to me how languages will add to this alist, when I'd 
> imagine they would be passive until such time as someone uses -t, 
> -*-...-*-, or :language...?

They don't.  There will be a standard alist for those supplied with
the guile distribution.  For others, the alist has to be extended in
.guile just as Emacs users extend auto-mode-alist in .emacs.

I'll add this to the document.

> In some languages you will want a different reader during interactive
> and non-interactive use.  For instance, in Python a blank line signals
> an end-of-block when interactive, but nothing when non-interactive.

OK, we'll add an interactive? flag to the port object.

> >   translate EXPRESSION --> SCHEMECODE
> > 
> >     Translate an EXPRESSION into SCHEMECODE.
> > 
> >     EXPRESSION can be anything returned by `read-expression'.
> > 
> >     SCHEMECODE is Scheme source code represented using ordinary Scheme
> >     data.  It will be passed to `eval' in an environment containing
> >     bindings in the environment returned by `language-environment'.
> > 
> >     This procedure will be called duing interactive use and when the
> >     system `eval
> 
> I'm unclear of why this would be necessary.  `read-expression' will
> probably have to parse the input fully to determine what a single
> expression is, making `translate' rather surpurfluous.  Why not just
> say that read-expression will have to return a Scheme expression?

read-expression (which I've renamed `native-read' in next version of
the proposal) is intended to be a back-end for `read'.  `translate'
will be called from `eval'.

> In almost all languages the only trully native representation of
> code is a string, though the output of the lexer is potentially
> non-ambiguous and compact.

Yes.  But with Guile, you'll want to go further in those languages.
We would like to be able to write a repl in ctax, wouldn't we?  :)

The idea is that the `read' exported from the R5RS library will
continue work when called from other languages, and will keep its
semantics.

A call to `read' simply means "read in an expression from PORT using
the syntax associated with that port".

It's actually not at all certain that we want to translate it.

> >   translate-all PORT --> THUNK
> > 
> >     Translate the entire stream of characters PORT until #<eof>.
> >     Return a THUNK which can be called repeatedly like this:
> > 
> >       THUNK --> SCHEMECODE
> > 
> >     Each call will yield a new piece of scheme code.  #f is returned
> >     to signal the end of the stream of scheme expressions.
> 
> This could cause a problem, as #f is a valid Scheme expression.  
> Maybe *eof-object* would be less ambiguous?

I don't think this is a problem.  We could even say that THUNK never
returns immediates, except for the last #f.  If an expression is
equivalent to #f, it is just skipped.

> >   untranslate SCHEMECODE --> EXPRESSION
> > 
> >     Attempt to do the inverse of `translate'.  An approximation is
> >     OK.  It is also OK to return #f.  This procedure will be called
> >     from the debugger, when generating error messages, backtraces etc.
> 
> How does the debugger know what the original language was for 
> SCHEMECODE?  Will eval deal with this internally?

The debugger can determine from which module an expression come.
(This is used currently to decide whether which backtrace frames to
display.  System modules use the option :no-backtrace to prevent
displaying of Guile's internals to the user.)
The module has information about the language.

> It might be good to explicitly say that untranslate can use
> source-properties set by the reader to give hints.

OK, will come in next version.

> Should there be some way of telling the translator if it should
> support debugging when loading a file?  It could potentially expand
> the code-size significantly to include all the expressions (and
> sub-expressions) in the code, as well as speed issues.

Hmm... good point.

Maybe `translate-all' should take an alist argument with "compilation
options"?