Inner functions and outer 'this' (Re: That hash symbol)

David Herman dherman at
Sun Mar 27 11:13:05 PDT 2011

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.


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 at

More information about the es-discuss mailing list