eval

Lars Hansen lhansen at adobe.com
Thu Mar 13 08:40:01 PDT 2008


> -----Original Message-----
> From: Waldemar Horwat [mailto:waldemar at google.com] 
> Sent: 12. mars 2008 19:08
> To: Lars Hansen
> Cc: Geoffrey Garen; es4-discuss Discuss
> Subject: Re: eval
> 
> Lars Hansen wrote:
> > In my opinion the following is roughly right:
> > 
> > obj.eval(x)
> > ...
> > 
> > eval(x)
> > ...
> 
> Seems reasonable, although anything dealing with eval evil 
> can get tricky.

No question about that.

> What about the other cases such as:
> 
> obj.foo(x)
> foo(x)
> new foo(x)
> 
> where foo happens to contain the original eval function.  Do 
> you try to do the eval, throw an EvalError, or do something 
> else?  

obj.foo(x) is fine if obj is the same global object that foo was
closed in; foo(x) is always fine.  In both cases, and like for
obj.eval, the environment that will be used for evaluation is
the global one.  

On the other hand, new foo(x) will not be allowed because the
'this' object is not a global object.

(EvalError is thrown at run-time in all these cases if an illegal
use is detected.)

In summary, if it is trivially lexically detectable that 
something could be an invocation of 'eval' (by the expression
having the abstract form M(E, ...) where M is "eval" or
"intrinsic::eval") then the invocation, if found at run-time
to be an invocation of the pre-defined eval function, will
have access to the lexical environment.  In all other cases
an invocation of eval is just a function/constructor call,
which only has access to the global environment it was
closed in;  the eval function body tests that its 'this'
object is the global object it was closed in and throws
an EvalError if it was not.

All of this is covered in greater detail (with background 
materials, rationale, etc) in the draft spec for the global
object.  What's written there is consistent with what I wrote
here earlier but probably better developed.

--lars



More information about the Es4-discuss mailing list