This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Language translation proposal


On Sat, Aug 12, 2000 at 10:33:43PM +0200, Mikael Djurfeldt wrote:
> > 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.

The read/eval concept only really exists in Lisp-like languages.  Read
and execute are obviously seperate, but that's something else
entirely.  I suppose read could return a parse-tree, or maybe the
concrete syntax (i.e., a list of lexical symbols), but what would be
the point?  Directly reading to a Scheme expression is more efficient,
and will make more sense in the context of most languages.

> > >     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.

That seems like a nuisance.  In a language that allows #f as a 
literal, each expression will have to be checked against #f to
avoid from premature termination.  Or, it can be ignored and once
in a blue moon someone will get a really weird error because
they included a lone false.

  -- Ian

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]