This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: Language translation proposal
- To: Ian Bicking <ianb at colorstudy dot com>
- Subject: Re: Language translation proposal
- From: Mikael Djurfeldt <mdj at mdj dot nada dot kth dot se>
- Date: 13 Aug 2000 05:38:22 +0200
- Cc: djurfeldt at nada dot kth dot se, guile at sourceware dot cygnus dot com
- Cc: djurfeldt at nada dot kth dot se
- References: <E13NUrg-0007ns-00@mdj.nada.kth.se><20000812145351.C727@localhost> <xy74s4qjk2g.fsf@mdj.nada.kth.se><20000812202159.A434@localhost>
- Reply-To: djurfeldt at nada dot kth dot se
Ian Bicking <ianb@colorstudy.com> writes:
> > 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?
I guess the main point is to support lisp-like languages.
A secondary point is to support the foreign language escape syntax
described in version 1.2 of the proposal.
> Directly reading to a Scheme expression is more efficient, and will
> make more sense in the context of most languages.
Well, efficiency is not needed when reading individual expressions.
Files are loaded using `translate-all' where the translator
implementor can do what he wants.
Still, if supporting `native-read' and `translate' turns out to be
clumsy, then we should of course consider removing it.
> > > > 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.
OK, now I see how you are thinking.
It's just that there's probably *no* value which is "safe" in this
respect. For example, we can't use *eof-object*, because most
languages will have expressions with values, and expression can be a
variable, and a variable can contain the #<eof-object>.
So, we have to check what we return anyway, and then we could just as
well use #f.
Or?