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 <bren...@mozilla.com> Date: Sat, Jul 24, 2010 at 10:28 PM Subject: Re: Rationalizing ASI (was: simple shorter function syntax) To: Maciej Stachowiak <m...@apple.com>, "Mark S. Miller" <erig...@google.com> Cc: es-discuss <es-discuss@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. /be
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
