Multiple globals and direct/indirect eval

David Herman dherman at
Thu Mar 3 21:22:21 PST 2011

Hi Jeff,

I agree that the spec should deal with multiple global objects. I'm aware of a few of the subtleties of multiple globals, but I wouldn't be surprised if there are more. Thanks for raising this one. I created a placeholder strawman last week, because I've been intending to get into this topic. I've given it some contents now, but there's more work to be done. Here's what I've got so far:

> The Chrome/Safari behavior would resurrect the vestigial EvalError, so I don't think it makes sense.  It also contradicts the specification of the steps in the definition of the eval function.

I think I agree with this.

> Firefox's behavior is inconsistent and seems not amenable to host-agnostic specification as ECMA would require.

I agree that we don't want things like the same-origin policy to show up in the ES spec. But I'm not sure I'm convinced there isn't a way to specify things loosely enough that the same-origin policy is consistent with whatever spec we end up with. I need to chew on that for a while, though.

> Thus we are left with the IE9/Opera behavior, which seems sensible and natural to me: an eval function should always act in the context of the global from which it came.

Now this I think I don't agree with. The reason is that direct eval is really a static operator in ECMAScript, not an ordinary function call. It's more than a function call because, for example, it has access to the lexical environment. Now, it has this strange dynamic component where, if the value turns out dynamically *not* to be an evaluation function, then it degenerates into a function call. But this doesn't change the fact that direct eval is imbued with special static-operator powers not available to other function calls -- in particular, access to the lexical environment.

At any rate, I can see two semantics that seem reasonable to me. First let me make up some terminology: an "apparently direct eval" is a call that's of the right form to be a direct eval, but whether it actually turns out to be a direct eval depends on the dynamic value of the callee.

So the two alternatives:

1) an apparently direct eval is a direct eval if its callee is *any* evaluation function
2) an apparently direct eval is a direct eval *only* if its callee is the evaluation function of the same global context as the call site

In either alternative, though, the global object of the eval'ed code is the same global object as the call site. At least for same-origin, semantics #1 agrees with what Firefox is doing. But either one makes sense to me.

As for the same-origin stuff, I'm not yet sure what I think. I'll need to be schooled in the implications for the browser security model.

> What needs to be done to standardize this behavior?  And more generally, what needs to be done to begin standardizing multiple globals in ECMAScript, including issues like this one?

The above wiki page is a step in that direction, but there's more work to do. One thing that I think we have to do is nail down the notion of what callee values constitute an actual direct eval. It's not enough to say "the eval function," which is as bogus a phrase as "the global object."


More information about the es-discuss mailing list