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 <dome...@domenicdenicola.com <mailto:dome...@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" <bren...@mozilla.org <mailto:bren...@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@mozilla.org <mailto:es-discuss@mozilla.org> > https://mail.mozilla.org/listinfo/es-discuss > _______________________________________________ es-discuss mailing list es-discuss@mozilla.org <mailto:es-discuss@mozilla.org> https://mail.mozilla.org/listinfo/es-discuss _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
