On Sat, Jul 24, 2010 at 11:28 PM, Mark S. Miller <[email protected]> wrote:
> First, I agree that we should gather and examine data before making any > decisions. That said, here are my data-free reactions. I may well change my > mind about any of this once we have data to examine. > > > On Sat, Jul 24, 2010 at 11:16 PM, Mark S. Miller <[email protected]>wrote: > >> 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 <[email protected]> >> Date: Sat, Jul 24, 2010 at 10:28 PM >> Subject: Re: Rationalizing ASI (was: simple shorter function syntax) >> To: Maciej Stachowiak <[email protected]>, "Mark S. Miller" < >> [email protected]> >> Cc: es-discuss <[email protected]> >> >> >> 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. >> > > This seems best to me. I would have no objection to keeping the second > bullet of ASI rule #1. I may even advocate keeping it; I'm not sure yet. > However, the first bullet of rule #1 is a terrible hazard. > I should add that I view ASI rule #2 as similar to the second bullet of ASI rule #1. It's harmless and helpful, and probably should be kept. > > >> >> 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. >> > > #B seems rather horrible to me. The restricted productions at least catch > some of the errors that ASI causes. I strongly prefer #C to #B. > > >> >> I don't see why you'd remove error correction but leave the restricted >> productions just to have a subset language. >> > > Agreed. Once we remove the ASI hazards, we should also remove > the inconveniences which are no longer needed to avoid these hazards. > > > >> 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 agree about the second bullet. I passionately disagree about the first > bullet. That first bullet is way more painful than the restricted > productions. > > >> >> 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. >> > > Yes! Data! Bring it on! > > >> >> /be >> >> >> > > > -- > Cheers, > --MarkM > -- Cheers, --MarkM
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
