This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: Language translation proposal
- To: djurfeldt at nada dot kth dot se
- Subject: Re: Language translation proposal
- From: Ian Bicking <ianb at colorstudy dot com>
- Date: Sat, 12 Aug 2000 20:21:59 -0500
- Cc: guile at sourceware dot cygnus dot com
- References: <E13NUrg-0007ns-00@mdj.nada.kth.se> <20000812145351.C727@localhost> <xy74s4qjk2g.fsf@mdj.nada.kth.se>
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