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
