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

[Allen Wirfs-Brock]

On Sep 27, 2012, at 10:54 PM, Brendan Eich wrote:

> 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 {...}?

In particular, this general concern was raised from the perspective of  an implementation that is trying to absolutely minimize semantic analysis during the initial parse phase.  Presumably it does not generate an AST at that time which makes it difficult to do any static analysis that isn't extremely local.  Also, the concern was not specifically about this set of argument rules but was more general about the growing set of early errors that we currently have in the ES6 spec. Individually most early errors are probably not particularly burdensome to such an implementation.  But collectively, they may well be. 

Implementation diversity is a good thing and we should be careful in our specifications to not unnecessarily limit such diversity.   Prior to ES5 there were very few "early errors" (the terminology wasn't even formalized) and early reporting of them was optional. ES5 added quite a few new ones (particularly related to strict mode) and made early reporting mandatory.  ES6 is on course to add many new early errors. Before we go too far with this, it seems reasonable to stop and consider the possible impact upon implementation deversity of requiring early reporting of a large number of error conditions. 

I propose we call this class of errors "deferred early errors".  They are statically detectable errors that could be reported at "load time".  What we are discussing is deferring their reporting (and implicitly their detection) to a point where it is definitively known that the erroneous code actually is used by the running program. To address, Domenic's concern a "deferred early error" is still required to be detectable solely from inspecting a source file prior to execution.  If we have them, it would seem to be a best practice for any developer to run an ahead-of time linter over all program before deployment.  That doesn't seem like a big burden and something that could easily be integrated into tool chains and development tools.

I see a potential benefit to implementor in the "deferred early error" concept and there are implementation alternatives that would be lost without it.  I see a minor negative impact to developers.  They would need to take an extra pre-deployment action in order to be sure that a ES source file does not violate any  ES static semantic restrictions.  To me this seems like a plausible cost/benefit trade-off. 

Allen