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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
