Global lexical tier

saam barati saambarati1 at
Thu Sep 3 17:42:54 UTC 2015

After reading through past threads and meeting notes, I've changed my
I think the current spec is OK and meets the real needs of programs today.
I've ran into real programs that break without the global lexical tier
while implementing
this inside JavaScriptCore. While I don't think global lexical tier is
aesthetically pleasing, I think
there is a practicality to it. I think we've also hurt ourselves here with
regards to considering alternate
implementations by having some form of "const" being visible across
multiple JS programs for a while now.


On Tue, Sep 1, 2015 at 7:41 PM, SaamBarati1 <saambarati1 at> wrote:

> Hi Allen,
> What were the requirements for the global lexical scope? Is it written
> somewhere I can read? I came up empty after a quick search of
> I think the whole point of ES6 lexical scoping is to limit scope to
> something you can read in a given file (or script, or block, or eval, or
> unit of JS code). Except, this breaks down for global top-level
> let/const/class. I argue that if you want these variables to be visible
> across JS programs, you should be using modules. The current spec makes
> this somewhat better than "var"s because these variables are no longer
> properties on the global object, but it punted and said that there is some
> magical lexical scope that wraps all programs. I think it's more in the
> spirit of lexical scoping to have these variables be limited to the program
> they're defined in (as if the entire program were wrapped in {}). And it's
> more in the spirit of ES6 to share code across programs using modules.
> I think it's not helpful for you to threaten that our opinions are less
> useful than a proof of impossibility when we are people who are both
> interested in the JavaScript language and interested in implementing it
> well. I've spent > 8 hours today implementing the "global lexical tier", so
> I think it's helpful to categorize my opinion as being slightly greater
> than "less useful than a proof that the spec is impossible to implement".
> Sometimes the best ideas are those that are negligent of "requirements".
> Saam
> > On Sep 1, 2015, at 11:39 AM, Allen Wirfs-Brock <allen at>
> wrote:
> >
> >
> > On Sep 1, 2015, at 11:04 AM, Geoffrey Garen wrote:
> >
> >>> The possible semantics of global lexical declarations was extensively
> explored by TC39 before we make the final design decisions for ES6.  The
> scoping of global lexical declarations is something we spent many hours
> discussing  over a span of several years, including:
> >>
> >> To be fair, some problems in design only become apparent after
> implementation and use.
> >>
> >> For example, in the case of global lexical scope, implementing and
> testing the details of the current ECMAScript specification led Saam to
> conclude — and led me to agree — that the behavior was strange, and hard to
> reason about.
> >>
> >> I hope you aren’t saying that ECMAScript decisions should become
> permanent and irreversible prior to any implementation or adoption effort.
> In other web standards, implementation and adoption guide specification —
> to the benefit of the specification.
> >>
> >> Geoff
> >
> > What I'm saying is that this is more about "requirements" than
> implementations. There was a complex (and sometimes conflicting) set of
> requirements for the semantics of the new global declarations.  The final
> design that TC39 accepted threaded the needle among those requirements. We
> were aware that some people (including some TC39 members) would probably
> find some aspects of the design might be strange or quirky. However, that
> tends to be the nature of solutions when dealing with complex requirements.
> >
> > Suggestions to change the design needs to address how each of those
> requirements can still met or why some of the requirements are not longer
> relevant.  Evidence that  the design is impossible to implement would be
> important news. But I don't think anybody has yet made that assertion.
> Observations that it is strange is less useful.  So are alternative designs
> that are presented without consideration of all of the initial requirements.
> >
> > Allen
> > _______________________________________________
> > es-discuss mailing list
> > es-discuss at
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the es-discuss mailing list