Allen Wirfs-Brock wrote:
On Sep 28, 2012, at 9:16 AM, Brendan Eich wrote:
Allen Wirfs-Brock wrote:
I generally use "static" to mean: solely based upon analysis of the program text
without any dependencies upon runtime state. That's my criteria for classifying something as
part of the language's static semantics" (which includes early errors).
Ok so far.
All ES errors (including early errors ) end up being reported at runtime.
No, here you redefine "runtime" from any useful definition. Of course stages nest or
recur fractally but in the browser, if a script loads and the first evaluation in it runs, you've
reached "runtime". And ES5 is quite clear that early errors -- including in nested
functions, *including in strict function*, must stop the whole script from reaching runtime.
It depends upon whether you are considering the "runtime" of an individual script or the
"runtime" of an application.
Clinton-esque. :-/
It depends on nothing. We know how scripts load today, how ES5 mandates
early errors. If you have a break to a non-existent/typo'ed label deep
in a function nest, the entire containing script fail-stops at compile
time without side effects.
This is a useful property, it's not something to throw away or try to
equate to function-wise tardy errors.
Most ES applications are composed of multiple scripts so the "early" point prior to
script runtime for a particular script is still usually somewhere in the middle of the
"runtime" of the application.
Yes, obviously -- but you seem to be equating that with a much finer
grained tardy error semantics that litters the heap with miscompiled
functions.
I think that's pretty wrong.
It's only a matter of how much, if any, execution is permitted before such
errors are reported.
You're still dodging the "use strict"; ES5 precedent point.
I said:
On Sep 28, 2012, at 8:46 AM, Allen Wirfs-Brock wrote:
On Sep 27, 2012, at 1:40 PM, Brendan Eich wrote:
More, you didn't respond to my "use strict"; point. Are you going to change whether
duplicate parameters with "use strict"; in the function prologue throw an early error, or
not?
My default is to make no changes to existing ES5 semantics without careful consideration
of the impacts. If we defer reporting of these new errors that we are discussing to a
latter point during execution it might be reasonable to also defer reporting of the ES5
"use strict" derived errors. That would presumably be a compatible change as
it relaxes an error condition.
No, you may break code that today works by a script fail-stopping
without effect, intentionally or accidentally. It's an incompatible
change and it won't fly.
Moreover, you are not considering the other alternative: add more early
errors in ES6 because they are no more onerous than ES5 strict checks
already in the field, and they build on sunk costs in those implementations.
The proximate example is duplicated formals in conjunction with new
parameter syntax (destructuring, defaults). If I missed a reply from you
on this, sorry. It would be good to get agreement on true early errors
for duplicated parameter names when mixed with new parameter syntax.
Doug, Andreas, and others (I bet Mark) agree.
But first we need to decide whether or not we are going to even have the concept of
"deferred early error" .
We do! Where's the list of candidate early error cases? Cc'ing Luke.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
