On Jan 19, 2011, at 10:58 PM, Mark S. Miller wrote:
> On Wed, Jan 19, 2011 at 10:06 PM, Brendan Eich <[email protected]> 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.
Don't break fab! I said.
Dave suggested a "use semicolons" pragma
(http://wiki.ecmascript.org/doku.php?id=strawman:pragmas), and this seems much
easier to swallow (speaking as a parser implementor). It would not break fab if
used, either.
/be
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
