Oliver Hunt wrote:
I'm generally against error on first call -- in the general case if you're able
to determine a function should fail on first execution you can determine that
it could fail during parsing and semantic analysis.
Ok, to play fair I should ask how you feel about any analysis that is
not "cheap enough" to do during a parse or lex/read pass required to
lazily compile functions on first call. What about binding analysis,
recognizing every statically resolvable use of a definition, possibly
making free variable uses early errors when inside module {...}?
/be
--Oliver
On Sep 27, 2012, at 9:01 PM, Brendan Eich<bren...@mozilla.org> wrote:
Domenic Denicola 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.
Totally agree!
Others on TC39 made this point too. We're not near consensus, unfortunately.
/be
On Sep 28, 2012, at 4:02, "Brendan Eich"<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
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
_______________________________________________
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
