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

[John Lenz]

The size of the average JS program is increasing in size faster than
machines are getting faster from where I sit.  Adding startup overhead
should be something TC39 is actively working against.

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!

On Thu, Sep 27, 2012 at 8:28 PM, Domenic Denicola <
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> 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
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120928/2d7fcfe9/attachment-0001.html>