namespaces and expression-qualified names

Lars Hansen lhansen at adobe.com
Fri Mar 21 10:00:58 PDT 2008


> -----Original Message-----
> From: es4-discuss-bounces at mozilla.org 
> [mailto:es4-discuss-bounces at mozilla.org] On Behalf Of Jon Zeppieri
> Sent: 21. mars 2008 09:49
> To: Jeff Dyer
> Cc: Brendan Eich; es4-discuss Discuss
> Subject: Re: namespaces and expression-qualified names
> 
> On Fri, Mar 21, 2008 at 11:12 AM, Jeff Dyer <jodyer at adobe.com> wrote:
> >
> > Names that can be resolved at compile time won't (can't) change 
> > meaning at  runtime. And names that are qualified by constant 
> > namespaces that appear in  the (safe) contexts you describe 
> above can 
> > be resolved at compile-time. So I  don't understand your charge of 
> > runtime qualifiers "defeating compile time  lookup". Please 
> elaborate.
> 
> I don't think we disagree about the facts.  I acknowledged in 
> my previous message that uses of runtime qualified lexical 
> bindings are like uses of the eval operator or with 
> statements: they can be statically detected, so an 
> implementation can optimize the cases where they are not 
> found.  What I meant by "defeating... &c." is simply that 
> when they are found, an implementation cannot perform this
> optimization:
> 
> function foo() {
>   var x = 5;
>   var y = 25;
> 
>   function bar(ns, n, v) {
>     var x = 10;
>     ns::[n] = v;
>   }
> }
> 
> The computed lookup has the same effect as eval: every 
> non-shadowed name in scope at the point where ns::[n] is 
> evaluated is up for grabs.
>  Only foo's x is safe, above.  So, yes, a lookup of foo's x 
> could be resolved ahead of time.  (An implementation may or 
> may not consider it worthwhile, though, to use hybrid 
> environment representations.)
> 
> The point of contention, I think, is this:
> 
> - eval has been changed in ES4 so that it would be possible 
> to detect cases where lexical bindings cannot be resolved 
> ahead of time.  Lars called the design "an obvious attempt at 
> killing 'eval' by a thousand cuts (yet remaining backward 
> compatible!)"  I took the comment to be suggesting that if 
> backwards compatibility were not an issue, eval wouldn't be 
> able to modify lexical bindings, at all.
> 
> - Brendan proposed a reformed with statement that wouldn't 
> interfere were lexical lookup the way the old with statement does.
> 
> Perhaps mistakenly, I took these as evidence that *only* 
> backwards compatibility concerns are keeping ES4 from 
> ensuring that all lexical bindings can be statically 
> resolved.  That's why I was surprised to find a new language 
> feature that inhibits static analysis in a manner similar to 
> old language features, which the designers are trying to kill.

The problem with the old 'eval' (as implemented in Firefox at
least) is that you can't tell when it is called, so any environment
anywhere is potentially changed at run-time, and must also be 
able to respond to run-time lookups by names.  Most people can
live with an 'eval' that's visible; it's the invisible one that
really hurts.

ns::[x] is like eval but it's visible.  with is visible.  These
are slow and expensive constructs under some implementation 
techniques, but that's not the real problem, because they are
mostly pay-as-you-go.

--lars



More information about the Es4-discuss mailing list