On Sep 27, 2012, at 1:40 PM, Brendan Eich wrote: > Allen Wirfs-Brock wrote: >> ... > >> I'm all for statically disallowing many of these "stupid" cases and I >> think it is fine to do the checks at "first call" rather than load-time (a >> off-line static linter could be more aggressive in reporting such errors). > > No. As a matter using accurate language, that's not "statically".
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). All ES errors (including early errors ) end up being reported at runtime. It's only a matter of how much, if any, execution is permitted before such errors are reported. No doubt there is more to be said about this on the other thread. > > 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. But first we need to decide whether or not we are going to even have the concept of "deferred early error" . Allen _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
