On Jul 10, 2008, at 3:28 PM, Mark S. Miller wrote:
On Thu, Jul 10, 2008 at 2:51 PM, Allen Wirfs-Brock <[EMAIL PROTECTED]
> wrote:
I see, yes there is a potential eval tax. If I thought this was
really a concern (and as you say, we already have the issue for
catch and such) I'd be more inclined to fiddling with the scoping
rule of eval rather than discarding lexically scoped consts. BTW, I
think many of the use cases for such const are more in support of
code generators then actual end user programming.
Could you explain the "eval tax" issue you guys are concerned about?
I don't get it. Thanks.
Because eval exposes lexical bindings by name in a way that is not
statically detectable, it defeats implementation techniques like
renaming or symbol versioning for block scope, and forces the use of
actual environment objects for blocks if they contain a call to eval.
For example:
function g(x)
{
if (x) {
const C = 0;
return eval(s1);
} else {
const C = 1;
return eval(s2);
}
}
Assuming s1 and s2 reference C, you at minimum need a separate runtime
symbol table for each block to allow the eval lookup to succeed. When
combined with closures and mutable block-scoped variables this can
force the creation of a full activation object per block that
introduces bindings.
And to avoid creating an activation object for every block (a huge
performance cost), an implementation would have to detect which blocks
introduce bindings, which contain calls to eval, and which contain
closures. Reasonable implementations do this anyway but I think it is
an unfortunate cost, even in ES4. In ES4, however, the benefit is
arguably greater.
Regards,
Maciej
_______________________________________________
Es4-discuss mailing list
Es4-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es4-discuss
