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

[Brendan Eich]

John Lenz wrote:
> The size of the average JS program is increasing in size faster than 
> machines are getting faster from where I sit.

Ahem, gmail, cough. :-/

>  Adding startup overhead should be something TC39 is actively working 
> against.

I take a different view, since as you say machines *are* getting faster. 
Not fast enough due to the power wall, so parallelism must be exploited 
safely.

More signfiicant: networks are getting faster and lower latency, and 
this shows up TCP's 90's era algorithms and default configury for cwnd 
etc. I expect changes at the transport layer to compensate, so suspect 
we'll be able to load more on demand.

Therefore I'm wagering that the problem ten years from now will be quite 
different from what you face today. Not just due to faster machines and 
'nets, but based on those, due to better ways of packaging and deploying 
JS (as source still, but possibly with fast-load properties we don't do 
right now; something like Doloto 
[http://research.microsoft.com/apps/pubs/default.aspx?id=70518], maybe).

Closing doors now based on fear of Parkinson's-Law overgrowth in the 
future does not seem like a good trade to me. Better would be 
pay-by-the-feature, so developers can choose to opt into early checking, 
or not. Thus the idea of module {...} getting free variable errors based 
on references that do not resolve to any lexical binding or global 
property available at compile time.

> The "early errors/first run errors" can be caught by other tools as 
> well (linters, in browser developer tools).  If said if the checks can 
> be implemented efficiently with near-zero overhead: great!

Could we have best of both? If module {...} gets early error for unbound 
free variable but this is considered onerous, perhaps we could separate 
the opt-in gesture a bit. I don't want a pragma, though. A devtool may 
not see all the actual global properties, so may flag false positives.

Food for thought, but win-win wins. Can we have it all?

/be
>
> On Thu, Sep 27, 2012 at 8:28 PM, Domenic Denicola 
> <domenic at domenicdenicola.com <mailto:domenic at domenicdenicola.com>> wrote:
>
>     As a user, not implementer, I really want early errors. Perf costs
>     of startup are negligible especially long-term. By the time ES6 is
>     in browsers computers and phones should be faster by enough of a
>     factor to mitigate any costs, whereas omitting early errors hurts
>     developers indefinitely into the future.
>
>     On Sep 28, 2012, at 4:02, "Brendan Eich" <brendan at mozilla.org
>     <mailto:brendan at mozilla.org>> wrote:
>
>     > Brendan Eich wrote:
>     >> We have not discussed error-on-first-call in this thread at all!
>     >
>     > This needs a separate thread. The idea from last week's TC39
>     meeting was to have not only
>     >
>     > * Early error, thrown before any code in the Program (grammar
>     goal symbol) containing the error, required by specific language
>     in Clause 16.
>     >
>     > * Runtime error, all the other kinds.
>     >
>     > and now
>     >
>     > * Error on first call to a function, where the function contains
>     what would be an early error but for the supposed cost of early
>     error analysis.
>     >
>     > The last case is really just a runtime error: a function with
>     what should be a static error becomes a booby trap: if your tests
>     happen to miss calling it, you'll feel ok, but a user who tickles
>     the uncovered path will get a runtime error.
>     >
>     > TC39 heard from some implementors who wanted to avoid more early
>     error requirements in ES6, or at least any that require analysis,
>     e.g. reaching definitions.
>     >
>     > That's fair as input to the committee, but implementation
>     concerns are not the only ones we weigh. And we were far from
>     agreed on adding the "Error on first call" category.
>     >
>     > The example you imply here would be
>     >
>     >  function f(a, b = c, a = d) {
>     >  }
>     >
>     > and the duplicate formal a would be illegal because of the novel
>     default-parameter syntax.
>     >
>     > Making f into a proximity-fused bomb does not see either good or
>     necessary. The analysis requires to notice duplicate formals is
>     trivial, and as I keep pointing out, ES5 already requires it:
>     >
>     >  function g(a, a) {
>     >    "use strict";
>     >  }
>     >
>     > This must be an early error per ES5 clause 16.
>     >
>     > Given the ES5-strict sunk cost, there's no added implementation
>     tax beyond the logic conjoining duplicate detection with
>     novel-syntax detection, which is trivial.
>     >
>     > It'd be good to hear from Luke on this.
>     >
>     > /be
>     > _______________________________________________
>     > es-discuss mailing list
>     > es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     > https://mail.mozilla.org/listinfo/es-discuss
>     >
>
>     _______________________________________________
>     es-discuss mailing list
>     es-discuss at mozilla.org <mailto:es-discuss at mozilla.org>
>     https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss