domenic at domenicdenicola.com (2014-10-15T18:58:52.701Z)
On Wed, Oct 8, 2014 at 2:51 PM, caridy <caridy at gmail.com> wrote:
> 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`.
I guess
```js
import {myGlobalFunction, MyPolyfilledConstructor} from Reflect.global;
```
then?
On Wed, Oct 8, 2014 at 2:51 PM, caridy <caridy at gmail.com> wrote: > 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`. I guess import {myGlobalFunction, MyPolyfilledConstructor} from Reflect.global; then? > ./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 >