Re: Translators again

[Ian Bicking <bickiia at earlham dot edu>]

On Wed, Feb 16, 2000 at 07:41:07PM +0100, Jost Boekemeier wrote:
> (eval list <environment>)
> 
> The function eval can be seen as a generic function.  It dispatches
> on its environment argument and calls the concrete (environment specific)
> method.  Same with eval-string, eval-int, eval-long or whatever you want.
> 
> I don't know if R5RS allows us to turn eval into a real GF, something
> like (eval <type> <environment>).  But it is important to understand that
> the "language selector" you want is the environment itself.

Okay, now I finally see what you're saying.  But do we want seperate 
environments for each language?  I could see reasons why that would
be best, but I could also see reasons why you'd want language and
environment too be more orthogonal than that.

I guess I'm not clear enough about how environments would actually
be used.  In some ways a Tcl environment is a must, because of
the dynamic scoping and all.  But how will that effect the ability
to use Tcl in any context where Scheme could be used?  Does the
need to construct a Tcl-specific environment mean that small
and scattered pieces of Tcl code will be infeasible?


eval definately *can't* dispatch on the first argument.  
(eval "(+ 1 2)") evaluates to "(+ 1 2)", after all.  But this is
because of the read/eval distinction that Scheme has which few other
languages really have -- well, I think many of them have it, but they
don't expose it in any way.  Tcl 8.0's byte-compiling is similar to
read, but you never see the bytecodes.  That's why I mentioned
eval-string (which is already part of Guile).  The canonical way
to represent code is generally strings, not lists, after all.

> Ian Bicking <bickiia@earlham.edu> writes:
> 
> > > [defining eval-string as:]
> > > >   (eval-string <some-input> #:language <some-language>)
> > > 
> > > In which module/environment?  
> > 
> > The global environment, I'd suppose.
> >   (eval-string <input> <environment> #:language <language>)
> > if you want to be explicit.  Isn't this how eval is supposed to
> > work?
> 
> Yes.  But the #:language <language> is redundant.  <environment>
> already knows this.  We have eval-environments, export-environments
> etc.  Nobody stops you from providing a tcl-eval-environment.

Suppose you have a clean translation -- something which tcl->scheme
isn't -- that is semantically identicle to Scheme but syntactically
different.  There's no reason you shouldn't be able to use that
syntax in any environment.  How do you force eval to use this
new syntax in a Scheme environment?


-- 
Ian Bicking         / 4869 N. Talman Ave. Apt. G, Chicago, IL 60625
bickiia@earlham.edu / http://www.cs.earlham.edu/~bickiia