Early error vs. error on first call to function vs. runtime error

Oliver Hunt oliver at apple.com
Wed Oct 3 11:05:59 PDT 2012

I'm against this entirely.  I don't see any reason to delay semantic checks, especially given one of the major purposes of strict mode was to convert unnecessarily late errors into early errors.

I still don't understand this desire to delay semantic analysis, where are the examples of sema being a performance bottleneck?  Just basic parsing already requires us to do a reasonable amount of analysis anyway, and while parsing shows up as being a problem, the bulk of that time seems to be lexing, and lexing is unavoidable even if all you want to do is syntactic analysis (unless we're proposing a delayed syntactic check mode?????)


On Sep 28, 2012, at 4:09 PM, Brendan Eich <brendan at mozilla.org> wrote:

> Claus Reinke wrote:
>> one might consider a <script provide>    with parse-on-use semantics?)
> This is a good idea. Instead of JS engines trying to do a cheap-yet-sound parse (or "read") of JS source, developers could say that they expect a <script> to be not frequently used enough to justify non-defer and non-"provide" semantics (eager loading).
> We do not want "developer mode" vs. "deploy mode" if it can be avoided. We want a way for developers to control latency hits, sorting JS into "hot" and "cold" paths at a coarse grain.
> /be
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss

More information about the es-discuss mailing list