On Sep 27, 2012, at 10:54 PM, Brendan Eich <[email protected]> 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 {...}?
I am still not sure whether modules are expected to have a containing scope,
but either way noticing free var references during parsing in not a problem
(why would it be?)
the reason I didn't say "all cases" is because resolution of an unbound global
property obviously can't be determined during parsing, it also doesn't make
sense to fail before the access (ignoring backwards compat issues entirely here
the obviate this problem).
I'm not sure what classes of error would warrant exception on initial execution
vs. just failing on sema, could you give an example?
--Oliver
>
> /be
>>
>> --Oliver
>>
>>
>> On Sep 27, 2012, at 9:01 PM, Brendan Eich<[email protected]> 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"<[email protected]> 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
>>>>> [email protected]
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>> _______________________________________________
>>>> es-discuss mailing list
>>>> [email protected]
>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> [email protected]
>>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> _______________________________________________
>> es-discuss mailing list
>> [email protected]
>> https://mail.mozilla.org/listinfo/es-discuss
>>
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
