namespaces and expression-qualified names

Jon Zeppieri jaz at bu.edu
Fri Mar 21 09:48:50 PDT 2008


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.



More information about the Es4-discuss mailing list