last time we discussed this, the conclusion was that `Reflect.global` is the way to go. more details here:
https://gist.github.com/ericf/a7b40bf8324cd1f5dc73#how-do-we-access-the-global-object-within-a-module

once realms landed, it will reflect `realm.global`.

./caridy

On Oct 8, 2014, at 8:52 AM, Andreas Rossberg <rossberg at google.com> wrote:

> On 8 October 2014 14:11, Brian Di Palma <offler at gmail.com> wrote:
>> I didn't realize how limited in power these fast parsers actually
>> were, they are basically lexers.
> 
> No, that's not correct. They have to perform a full syntax check. That
> does not imply binding analysis, though, which is usually regarded
> part of the static semantics of a language, not its (context-free)
> syntax. (More by accident than by design, JavaScript so far didn't
> have much of a static semantics -- at least none that would rule out
> many programs, i.e., induce compile-time errors. Hence engines could
> get away with lazy compilation so well.)
> 
>> I'm doubtful that it would have a significant user perceivable effect though.
>> I imagine modern browser engines perform a lot of work in parallel
>> where they can.
> 
> Unfortunately, parallelism doesn't help here, since this is all about
> the _initial_ parse (of every source), which has to happen before
> anything else, and so directly affects start-up times.
> 
>> One way around having an impact on current workloads is to only parse
>> in this fashion for modules.
> 
> Yes, see the earlier posts by Dave an myself. Didn't happen, though.
> 
>> As these modules would be stand alone fast parsing should be
>> embarrassingly parallel.
> 
> You can indeed parallelise parsing and checking of separate modules,
> but each individual task would still take longer, so there would still
> have been a potential overall cost.
> 
>> Yes hoisting is another complication, more bookkeeping, it will
>> probably delay when an error can be raised.
>> But would you not have to deal with it anyway? Can you not export a
>> hoisted function?
> 
> Yes, as I said, recursive scoping (a.k.a. "hoisting") is neither a new
> nor a significant problem.
> 
>> Fully closed modules are as you said are probably too tedious - that
>> can be dropped.
>> It's more about making modules closed against user defined state as
>> opposed to system defined state.
> 
> Yes, but unfortunately, you cannot distinguish between the two in
> JavaScript -- globals, monkey patching, and all that lovely stuff.
> 
> /Andreas
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

last time we discussed this, the conclusion was that `Reflect.global` is the way to go. more details here:
https://gist.github.com/ericf/a7b40bf8324cd1f5dc73#how-do-we-access-the-global-object-within-a-module

once realms landed, it will reflect `realm.global`.