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 <erig...@google.com> 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 <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.
>
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.
>
> 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
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
