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 <[email protected]> wrote: > On 8 October 2014 14:11, Brian Di Palma <[email protected]> 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 > [email protected] > https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
