The questions about eval look mostly unproblematic to me. In ES5-strict and
Harmony, eval is unable to modify its caller's scope. In legacy mode, I imagine
the semantics would be pretty straightforward, if problematic; but eval being
able to affect its caller's scope is problematic anyway, so it doesn't really
bother me.
The bigger issue is that scoping mechanisms in the de Bruijn tradition are
brittle for programming. They make sense as intermediate representations or
notations for proof frameworks, because they can (sometimes) be easier to
reason about formally, but they're fragile in the face of refactoring.
To be fair, your suggestion is more moderate than de Bruijn, although it's not
clear whether you're proposing the ability to refer to shadowed bindings of
*all* variables or just |this|. If it's the former, I'm *strongly* opposed. If
it's the latter, well, I guess I'm still pretty opposed, just maybe less
strongly. :)
Seriously, the problem you're trying to solve is that |this| is too fragile in
the face of refactoring, but you're solving it with a mechanism that's just as
sensitive to refactoring. It does make it syntactically simpler to fix than
|var self = this|, but the fix is just as brittle to the next refactoring. And
people already know how to use |var self = this|, so this would just introduce
one more programming pattern you have to teach people for dealing with
|this|-capture, but a less robust pattern than the one they already have.
But more broadly, my problem with this suggestion is that it's too drastic a
semantic change for the specific problem it's addressing. I much prefer the
space we've been exploring that allows for explicit binding of `this'. It's
more robust and less disruptive a change to lexical scoping.
Dave
On Mar 27, 2011, at 9:39 AM, Claus Reinke wrote:
>> Further, how would this interact with eval introducing (or in some systems
>> even removing) lexical bindings?
>
> Disclaimer 1: the Berkling-style systems I'm familiar with did not support
> eval, so I cannot argue from experience here
>
> Disclaimer 2: the reason for this was that unlimited reflection
> support breaks all equational theories about programs
> (eg toString can distinguish otherwise semantically
> equivalent programs, so only identical programs can be
> considered equal if reflection is taken into account) and
> equational reasoning was core to reduction languages
>
> Eval already breaks lexical scoping, so there is little hope of it having no
> interactions with extensions of lexical scoping.
>
> One might limit "eval('code')" not to have any effect on
> the context's lexical scope chain, but that would indeed
> limit eval's functionality (the eternal conflict between
> expressiveness and reasoning). Limiting eval/toString
> to be unaffected by the context's local scope chain would
> also be possible, but again, that would mean changing
> a lot of code.
>
> Since all that an implementation or programmer has to go with in the presence
> of eval is the lexical scope chain at any point of execution, adding
> protection is probably not going to make matters worse wrt eval. Similarly,
> toString can already distinguish between codes that
> differ only by renaming.
>
> Is that sufficiently vague / reassuring?-)
>
>> Nevertheless this 35-year-old idea seems fresh in the context of ECMAScript
>> development, and worth thinking about, so thanks for bringing it up.
>
> Always happy to promote a good idea!-)
>
> Claus
>
> _______________________________________________
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
