Rationalizing ASI (was: simple shorter function syntax)

[Mark S. Miller]

On Sat, Jul 24, 2010 at 11:28 PM, Mark S. Miller <erights at google.com> 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 <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.
>

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