On Jan 20, 2011, at 11:50 AM, Brendan Eich wrote:
> On Jan 19, 2011, at 10:58 PM, Mark S. Miller wrote:
>
>> On Wed, Jan 19, 2011 at 10:06 PM, Brendan Eich <bren...@mozilla.com> wrote:
>> On Jan 19, 2011, at 5:23 PM, Waldemar Horwat wrote:
>>
>>> MarkM: If we're making a harmonizer, let's get rid of semicolon
>>> insertion as well.
>>
>> For the record, I argued that we have only a handful of fingers to count
>> breaking changes in Harmony.
>>
>> Actually, I was asking about either getting rid of ASI or finding some
>> helpful reform of it. I did not stress this and did not correct anyone when
>> they assumed I was talking only about getting rid of it.
>
> Thanks, this helps.
>
>
>> So, for that same record (;)), here's my thinking on reforming ASI. The
>> following "rule" is not intended to be how parsers would actually think
>> about the rule, but rather how users could think about it:
>>
>> Parse the program once to AST1 using standard ASI rules.
>> Parse it again to AST2 using the aggressive-ASI rule defined below.
>> If both parses succeed and these ASTs are different, statically reject the
>> program.
>>
>> Agressive ASI rule:
>> Every time the parser reaches a newline, if preceding the newline is a well
>> formed expression, which would form a well formed expression statement if we
>> inserted a semicolon here, then insert the semicolon.
>>
>>
>> For example, under ASI
>> a()
>> (function(){...})()
>
> Recapping from today's TC39 meeting: this is an interesting idea, but does it
> require potentially costly forked parsing? Backtracking? What if there's a
> syntax error later?
>
> Main points for me are: the exact case shown here is a problem in practice,
> not due to ASI kicking in but due to it *not* kicking in. So there's a bug to
> fix, somehow. But: fixing it as proposed (assuming the proposal holds
> together) would break fabjs.
I'd always considered the safest (at least to my mind) solution for removing
ASI would be to produce a syntax error at an point ASI would be necessary in
the existing spec.
This wouldn't require backtracking, and wouldn't produce any weird differences
in behaviour between non-ASI mode vs ASI (if your code triggers ASI it would
fail to parse in non-ASI mode).
--Oliver
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
