Jan 19 meeting notes

Brendan Eich brendan at mozilla.com
Thu Jan 20 11:50:44 PST 2011

On Jan 19, 2011, at 10:58 PM, Mark S. Miller wrote:

> On Wed, Jan 19, 2011 at 10:06 PM, Brendan Eich <brendan at 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.

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.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110120/01574fa8/attachment.html>

More information about the es-discuss mailing list