This is the mail archive of the guile@sourceware.cygnus.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: Translators again



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


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.


Jost

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