Rationalizing ASI (was: simple shorter function syntax)

[Mark S. Miller]

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 <erights at 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 <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.
>

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20100724/f4d3a693/attachment-0001.html>