[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

question: EVAL

    Date: Fri, 21 Nov 86 17:49:44+0900
    From: Masayuki Ida <a37078%ccut.u-tokyo.junet%utokyo-relay.csnet@RELAY.CS.NET>
    In the list of GLS, there is an EVAL extension to have an optional argument
    for 'environment'.
    will it be defined in the comming specification ?
    Is this only one argument ?
    Does the value of this optional 'environmental' argument have a defined
    syntax/semantics ?

I have no qualms at all about adding the ability to address the
current macro-expansion environment, and to pass it to eval.  I have
real difficulty with the ability to pass the complete lexical
environment.I think the issue of whether to add complete environments
for eval is one of the more controvercial ones in "the list of GLS".

Having the ability to pass a lexical environment assumes the
ability to access the lexical environment. There is currently 
no way to access this, it is implicitly passed by eval to 
evalhooks, and so on.  Let me assume that you also want a way
to access the current lexical environment, say by a function

I think any code which uses this environment would be impossible to
compile, in the sense that the compiler probably couldn't do much
with it. This would hold for the entire body of lexically surrounding
code. For example:

(defun wierd-function (s-expression)
  (block here
    (tagbody :tag
       (let ((x (foo s-expression)))
        (labels ((bar (y) (+ x y)))
          (eval s-exp (get-current-env)))))))

The s-expression could draw on any of the environment here, so 
we can't optimize anything out of the environment. We can achieve
the desired effect by writing:

(defun wierd-function (s-expression)
  (eval `(block here
          (tagbody :tag
            (let ((x (foo s-expression)))
             (labels ((bar (y) (+ x y)))

Which is probably just about as good as the compiler could do anyway
and doesn't use any environments.

...mike beckerle
Gold Hill Computers