Fwd: Rationalizing ASI (was: simple shorter function syntax)

Mark S. Miller erights at google.com
Sat Jul 24 23:16:16 PDT 2010

Hi Brendan, I started to reply, but found it too confusing to talk about
options #1, #2, and #3 and about ASI rules #1, #2, and #3. I'm resending
your text edited with your options relabeled as #A, #B, and #C. I'll then
reply to this edited version. I encourage others to do likewise.

---------- Forwarded message ----------
From: Brendan Eich <brendan at mozilla.com>
Date: Sat, Jul 24, 2010 at 10:28 PM
Subject: Re: Rationalizing ASI (was: simple shorter function syntax)
To: Maciej Stachowiak <mjs at apple.com>, "Mark S. Miller" <erights at google.com>
Cc: es-discuss <es-discuss at mozilla.org>

On Jul 24, 2010, at 3:38 PM, Maciej Stachowiak wrote:

>> ASI has two parts: syntax error correction + restricted productions. The
pain users feel from ASI in my experience is mostly not from the
well-specified error correction part. It's mainly due to those infernal
restricted productions, especially
>> ReturnStatement:
>>   return [no LineTerminator here] Expressionopt ;
> That's a good point. If we had a "disable ASI" mode, would it just insert
syntax errors wherever a semicolon would have been inserted, or would it
make statements that could be valid multiline statements but for ASI have
their expected multiline meaning? The latter would remove more of the
annoyance of ASI, but it wouldn't be a subset of the language. I could see
an argument for either, or for no change.

I see three tenable alternatives:

A. Remove ASI in some opt-in version, in full -- no error correction, no
restricted productions.

B. Remove ASI's restricted productions in some opt-in version, but keep the
error correction aspect of ASI (i.e., remove rule 3 of the three rules of
ASI at ECMA-262 7.9.1).

C. No change.

I don't see why you'd remove error correction but leave the restricted
productions just to have a subset language. We're adding new syntax to
Harmony edition(s). Beyond this, the source of most ASI pain is the
restricted productions. Error correction, especially via ASI rule 1 second
bullet (inserting a ; before a }) is a win for usability.

I strongly suspect we'll stick with #C indefinitely, but I'm open to
discussing #B briefly. Better than discussing would be some
codesearch.google type study of a large swath of web JS, measuring how much
would break under #B.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100724/5a3b6825/attachment.html>

More information about the es-discuss mailing list