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

[John Lenz]

On Fri, Sep 28, 2012 at 11:14 AM, Brendan Eich <brendan at mozilla.org> wrote:

> 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. :-/


Spreadsheets, document editor, photo editor, games, emcascript apps, GWT
enterprise applications, etc, etc.  People are trying to do big things in
JavaScript and we should be trying to enable bigger things.


>
>
>   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.
>

Mobile networks have significantly increased latency (radio startup time,
etc) and networks are unreliable, but yes the best case scenarios are
getting better.  But predicting the future is something now one is really
good at.  Making sure we don't make thing worse today is more the point.


>
> 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<http://research.microsoft.com/apps/pubs/default.aspx?id=70518>],
> maybe).
>

The application I work with already do significant lazy loading of
functionality.  Doloto itself is a failed idea (late loading arbitrary
functions on unreliable networks), load points need to be controlled, but
this is besides the point.

The best thing I see for the future is if the Browser vendors didn't
reparse JavaScript when loading from cache, this would help the best case
scenarios, but doesn't help the worse case where it harder to find wins.


>
> 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.
>
>
Opt-in, earlier checks would be good for development.


> 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@**domenicdenicola.com<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<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<https://mail.mozilla.org/listinfo/es-discuss>
>>
>>
>> ______________________________**_________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/**listinfo/es-discuss<https://mail.mozilla.org/listinfo/es-discuss>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120928/602d9303/attachment.html>