Make comma at the end of line optional

classic Classic list List threaded Threaded
58 messages Options
123
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Naveen Chawla
I'm not really familiar with ASI but they key factor mentioned in this discussion is this (by Claude Pache):

*A implicit semicolon is not added when a declaration would be complete, but when the next token would produce a syntax error. *

By this behaviour (a modification to the initial "complete statement produces comma" version of this proposal), everything would work perfectly, no?

The multi-line get would not produce a comma, and hence the scheme is backwards compatible, right?

Please provide a counter-example if I have missed something.

As for the benefit, the time savings in not having to debug accidentally omitted commas and not having to add them in the first place are, I think, an improvement. And of course those who want to continue using commas everywhere, can:

```js
function doStuff(
    x
    y
    z
){
}
```

```
const
   x = 5
   y = 6
   z = 7
```

Great to hear those counter-examples as I don't know enough about ASI, and the related subject, to picture the pitfalls (sorry for my ignorance on this). Also it would be good for reference on this proposal...

On Wed, 13 Sep 2017 at 18:40 Boris Zbarsky <[hidden email]> wrote:
On 9/13/17 9:05 AM, Naveen Chawla wrote:
> Can someone remind me of the problem doing it this way, if any?

You mean apart from all the existing footguns ASI has?

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Jeremy Martin
Quick side note regarding multiple variable declarations: both versions of this proposal (OP's newline-based proposal and the ASI-inspired version) result in code breakage:

```
const
   x = 5
   y = 6
   z = 7
```

Under existing ASI rules, this is currently equivalent to:

```
const x = 5;
// y and z are global
y = 6;
z = 7;
```

If we use newline based comma insertion (or give ASI-style comma insertion precedence over semicolon insertion), then this proposal would result in the following equivalent:

```
const
  x = 5,
  // y and z are now lexically scoped constants
  y = 6,
  z = 7;
```

Unless I'm missing something, both of those scenarios definitely preclude multiple variable declarations from this proposal.

That being said, the ASI-inspired semantics seems like it could have more legs in other contexts, although I would personally argue that too little is offered in exchange for the cognitive overhead of a new rule with ASI-style exceptions attached to it (i.e.., "comma before newlines, except after get, and set, variable declarations, ...").


On Wed, Sep 13, 2017 at 9:57 AM, Naveen Chawla <[hidden email]> wrote:
I'm not really familiar with ASI but they key factor mentioned in this discussion is this (by Claude Pache):

*A implicit semicolon is not added when a declaration would be complete, but when the next token would produce a syntax error. *

By this behaviour (a modification to the initial "complete statement produces comma" version of this proposal), everything would work perfectly, no?

The multi-line get would not produce a comma, and hence the scheme is backwards compatible, right?

Please provide a counter-example if I have missed something.

As for the benefit, the time savings in not having to debug accidentally omitted commas and not having to add them in the first place are, I think, an improvement. And of course those who want to continue using commas everywhere, can:

```js
function doStuff(
    x
    y
    z
){
}
```

```
const
   x = 5
   y = 6
   z = 7
```

Great to hear those counter-examples as I don't know enough about ASI, and the related subject, to picture the pitfalls (sorry for my ignorance on this). Also it would be good for reference on this proposal...

On Wed, 13 Sep 2017 at 18:40 Boris Zbarsky <[hidden email]> wrote:
On 9/13/17 9:05 AM, Naveen Chawla wrote:
> Can someone remind me of the problem doing it this way, if any?

You mean apart from all the existing footguns ASI has?

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
661.312.3853

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Алексей
Yes, this is the reason why I didn't mention the variable declaration in initial proposal - it is 100% valid syntax in current implementation (and 100% relative error in strict mode)

But the design problems of ASI are incomparable with a special case of get and set

2017-09-13 17:55 GMT+03:00 Jeremy Martin <[hidden email]>:
Quick side note regarding multiple variable declarations: both versions of this proposal (OP's newline-based proposal and the ASI-inspired version) result in code breakage:

```
const
   x = 5
   y = 6
   z = 7
```

Under existing ASI rules, this is currently equivalent to:

```
const x = 5;
// y and z are global
y = 6;
z = 7;
```

If we use newline based comma insertion (or give ASI-style comma insertion precedence over semicolon insertion), then this proposal would result in the following equivalent:

```
const
  x = 5,
  // y and z are now lexically scoped constants
  y = 6,
  z = 7;
```

Unless I'm missing something, both of those scenarios definitely preclude multiple variable declarations from this proposal.

That being said, the ASI-inspired semantics seems like it could have more legs in other contexts, although I would personally argue that too little is offered in exchange for the cognitive overhead of a new rule with ASI-style exceptions attached to it (i.e.., "comma before newlines, except after get, and set, variable declarations, ...").


On Wed, Sep 13, 2017 at 9:57 AM, Naveen Chawla <[hidden email]> wrote:
I'm not really familiar with ASI but they key factor mentioned in this discussion is this (by Claude Pache):

*A implicit semicolon is not added when a declaration would be complete, but when the next token would produce a syntax error. *

By this behaviour (a modification to the initial "complete statement produces comma" version of this proposal), everything would work perfectly, no?

The multi-line get would not produce a comma, and hence the scheme is backwards compatible, right?

Please provide a counter-example if I have missed something.

As for the benefit, the time savings in not having to debug accidentally omitted commas and not having to add them in the first place are, I think, an improvement. And of course those who want to continue using commas everywhere, can:

```js
function doStuff(
    x
    y
    z
){
}
```

```
const
   x = 5
   y = 6
   z = 7
```

Great to hear those counter-examples as I don't know enough about ASI, and the related subject, to picture the pitfalls (sorry for my ignorance on this). Also it would be good for reference on this proposal...

On Wed, 13 Sep 2017 at 18:40 Boris Zbarsky <[hidden email]> wrote:
On 9/13/17 9:05 AM, Naveen Chawla wrote:
> Can someone remind me of the problem doing it this way, if any?

You mean apart from all the existing footguns ASI has?

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
<a href="tel:(661)%20312-3853" value="+16613123853" target="_blank">661.312.3853

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Boris Zbarsky
In reply to this post by Naveen Chawla
On 9/13/17 9:57 AM, Naveen Chawla wrote:
> By this behaviour (a modification to the initial "complete statement
> produces comma" version of this proposal), everything would work
> perfectly, no?

If by "perfectly" you mean "have hard-to-predict somewhat nonlocal
behavior that makes any code relying on this a hard-to-read footgun",
then the answer might be "yes".  For pretty much any other definition of
"perfectly", I'm fairly sure the answer is "no".

> Great to hear those counter-examples as I don't know enough about ASI,

Still in the context of ASI, here are some examples of why ASI is a bad
idea:

1) What does this return?

   function f() {
     return
     5;
   }

2) What does this alert?

   var str = "hello";
   var x = str
   [x].forEach(() => alert(x))

Now back to automatic comma insertion... In your example:

   function doStuff(
       x
       y
       z
   ){
   }

if someone changes doStuff to take an array as the second arg and you
modify the call as:

   function doStuff(
       x
       [y]
       z
   ){
   }

suddenly you need to insert a comma after the "x" to preserve the right
semantics, no?  This is not terribly intuitive or obvious.  It gets even
worse in a situation like this:

   function doStuff(
       x
       /* The next argument is an array for good reasons that we
          will now expound on in a long comment, etc, etc */
       [y]
   ){
   }

Quick, tell me without testing this or looking at the spec for a while
whether this is a valid call to doStuff, with one argument, or a syntax
error that would trigger comma insertion.

But more generally, if you just use your favorite search engine on the
phrase "automatic semicolon insertion", you will get a slew of articles
explaining the pitfalls.

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Naveen Chawla
`x` <whitespace> `[y]` would be invalid syntax, right?
So
```js
x
[y]
```
would automatically insert a comma in the case of a function call arguments list, right?

That's exactly what would be desired. What am I missing?

On Wed, 13 Sep 2017 at 20:52 Boris Zbarsky <[hidden email]> wrote:
On 9/13/17 9:57 AM, Naveen Chawla wrote:
> By this behaviour (a modification to the initial "complete statement
> produces comma" version of this proposal), everything would work
> perfectly, no?

If by "perfectly" you mean "have hard-to-predict somewhat nonlocal
behavior that makes any code relying on this a hard-to-read footgun",
then the answer might be "yes".  For pretty much any other definition of
"perfectly", I'm fairly sure the answer is "no".

> Great to hear those counter-examples as I don't know enough about ASI,

Still in the context of ASI, here are some examples of why ASI is a bad
idea:

1) What does this return?

   function f() {
     return
     5;
   }

2) What does this alert?

   var str = "hello";
   var x = str
   [x].forEach(() => alert(x))

Now back to automatic comma insertion... In your example:

   function doStuff(
       x
       y
       z
   ){
   }

if someone changes doStuff to take an array as the second arg and you
modify the call as:

   function doStuff(
       x
       [y]
       z
   ){
   }

suddenly you need to insert a comma after the "x" to preserve the right
semantics, no?  This is not terribly intuitive or obvious.  It gets even
worse in a situation like this:

   function doStuff(
       x
       /* The next argument is an array for good reasons that we
          will now expound on in a long comment, etc, etc */
       [y]
   ){
   }

Quick, tell me without testing this or looking at the spec for a while
whether this is a valid call to doStuff, with one argument, or a syntax
error that would trigger comma insertion.

But more generally, if you just use your favorite search engine on the
phrase "automatic semicolon insertion", you will get a slew of articles
explaining the pitfalls.

-Boris

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Bob Myers
Personally, I am annoyed by the extra typing required for spaces.
I propose that we have a new kind of ASI: automatic SPACE insertion.

For instance, you could then write

```js
    functionfoobar(){return42;}
```js




On Wed, Sep 13, 2017 at 11:25 PM, Naveen Chawla <[hidden email]> wrote:
`x` <whitespace> `[y]` would be invalid syntax, right?
So
```js
x
[y]
```
would automatically insert a comma in the case of a function call arguments list, right?

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Isiah Meadows-2
What about...

- variable (var)

- donuts (do)

- forest (for)

- awaiter (await, module-specific)

- async (https://github.com/caolan/async)

- className (class)

- letters (let)

- constants (const)

Fun fact: all of these are valid, and many of them are relatively common. Please consider the ramifications of such a feature before proposing them.

On Wed, Sep 13, 2017, 14:22 Bob Myers <[hidden email]> wrote:
Personally, I am annoyed by the extra typing required for spaces.
I propose that we have a new kind of ASI: automatic SPACE insertion.

For instance, you could then write

```js
    functionfoobar(){return42;}
```js




On Wed, Sep 13, 2017 at 11:25 PM, Naveen Chawla <[hidden email]> wrote:
`x` <whitespace> `[y]` would be invalid syntax, right?
So
```js
x
[y]
```
would automatically insert a comma in the case of a function call arguments list, right?
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Tab Atkins Jr.
I believe Bob was engaging in reductio ad absurdum, Isiah. ^_^

On Wed, Sep 13, 2017 at 11:51 AM, Isiah Meadows <[hidden email]> wrote:

> What about...
>
> - variable (var)
>
> - donuts (do)
>
> - forest (for)
>
> - awaiter (await, module-specific)
>
> - async (https://github.com/caolan/async)
>
> - className (class)
>
> - letters (let)
>
> - constants (const)
>
> Fun fact: all of these are valid, and many of them are relatively common.
> Please consider the ramifications of such a feature before proposing them.
>
> On Wed, Sep 13, 2017, 14:22 Bob Myers <[hidden email]> wrote:
>>
>> Personally, I am annoyed by the extra typing required for spaces.
>> I propose that we have a new kind of ASI: automatic SPACE insertion.
>>
>> For instance, you could then write
>>
>> ```js
>>     functionfoobar(){return42;}
>> ```js
>>
>>
>>
>>
>> On Wed, Sep 13, 2017 at 11:25 PM, Naveen Chawla <[hidden email]>
>> wrote:
>>>
>>> `x` <whitespace> `[y]` would be invalid syntax, right?
>>> So
>>> ```js
>>> x
>>> [y]
>>> ```
>>> would automatically insert a comma in the case of a function call
>>> arguments list, right?
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Isiah Meadows-2
Oh okay. Granted, that's not always a safe assumption on this list, though...

(It's actually a bit of a refreshing surprise when people present well-researched proposals here, to be honest.)

On Wed, Sep 13, 2017, 15:00 Tab Atkins Jr. <[hidden email]> wrote:
I believe Bob was engaging in reductio ad absurdum, Isiah. ^_^

On Wed, Sep 13, 2017 at 11:51 AM, Isiah Meadows <[hidden email]> wrote:
> What about...
>
> - variable (var)
>
> - donuts (do)
>
> - forest (for)
>
> - awaiter (await, module-specific)
>
> - async (https://github.com/caolan/async)
>
> - className (class)
>
> - letters (let)
>
> - constants (const)
>
> Fun fact: all of these are valid, and many of them are relatively common.
> Please consider the ramifications of such a feature before proposing them.
>
> On Wed, Sep 13, 2017, 14:22 Bob Myers <[hidden email]> wrote:
>>
>> Personally, I am annoyed by the extra typing required for spaces.
>> I propose that we have a new kind of ASI: automatic SPACE insertion.
>>
>> For instance, you could then write
>>
>> ```js
>>     functionfoobar(){return42;}
>> ```js
>>
>>
>>
>>
>> On Wed, Sep 13, 2017 at 11:25 PM, Naveen Chawla <[hidden email]>
>> wrote:
>>>
>>> `x` <whitespace> `[y]` would be invalid syntax, right?
>>> So
>>> ```js
>>> x
>>> [y]
>>> ```
>>> would automatically insert a comma in the case of a function call
>>> arguments list, right?
>>
>> _______________________________________________
>> es-discuss mailing list
>> [hidden email]
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> _______________________________________________
> es-discuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/es-discuss
>

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Jeremy Martin
In reply to this post by Naveen Chawla
> What am I missing?

Nothing with respect to function arguments, AFAICT.

But to beat the dead-cognitive-overhead horse again, the rules around ACI (Automatic Comma Insertion) appear to require too many exceptions. We've already covered:
  • ACI doesn't apply at all between variable declarations
  • ACI has exceptions around getter/setter properties in object literals.
I hadn't thought of these before, but there's also:
  • ACI would need exceptions in object and array literals following yield in generator functions.
  • ACI would need exceptions in object and array literals following await in async functions.
I would wager this isn't an exhaustive list yet, either.

To be clear, these aren't exceptions in the grammar itself (the ASI-style "insert comma if next token would generate a syntax error" is sufficient to handle all of these cases), but they are exceptions that developers and tooling would need to hold onto, and IMHO, relegate the purported readability improvements.

On Wed, Sep 13, 2017 at 1:55 PM, Naveen Chawla <[hidden email]> wrote:
`x` <whitespace> `[y]` would be invalid syntax, right?
So
```js
x
[y]
```
would automatically insert a comma in the case of a function call arguments list, right?

That's exactly what would be desired. What am I missing?

On Wed, 13 Sep 2017 at 20:52 Boris Zbarsky <[hidden email]> wrote:
On 9/13/17 9:57 AM, Naveen Chawla wrote:
> By this behaviour (a modification to the initial "complete statement
> produces comma" version of this proposal), everything would work
> perfectly, no?

If by "perfectly" you mean "have hard-to-predict somewhat nonlocal
behavior that makes any code relying on this a hard-to-read footgun",
then the answer might be "yes".  For pretty much any other definition of
"perfectly", I'm fairly sure the answer is "no".

> Great to hear those counter-examples as I don't know enough about ASI,

Still in the context of ASI, here are some examples of why ASI is a bad
idea:

1) What does this return?

   function f() {
     return
     5;
   }

2) What does this alert?

   var str = "hello";
   var x = str
   [x].forEach(() => alert(x))

Now back to automatic comma insertion... In your example:

   function doStuff(
       x
       y
       z
   ){
   }

if someone changes doStuff to take an array as the second arg and you
modify the call as:

   function doStuff(
       x
       [y]
       z
   ){
   }

suddenly you need to insert a comma after the "x" to preserve the right
semantics, no?  This is not terribly intuitive or obvious.  It gets even
worse in a situation like this:

   function doStuff(
       x
       /* The next argument is an array for good reasons that we
          will now expound on in a long comment, etc, etc */
       [y]
   ){
   }

Quick, tell me without testing this or looking at the spec for a while
whether this is a valid call to doStuff, with one argument, or a syntax
error that would trigger comma insertion.

But more generally, if you just use your favorite search engine on the
phrase "automatic semicolon insertion", you will get a slew of articles
explaining the pitfalls.

-Boris

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
661.312.3853

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Isiah Meadows-2

If something requires so much special casing just to work, it's fundamentally broken and best avoided altogether. Sloppy mode is fundamentally broken. `eval` is fundamentally broken. TC39 people have already generally accepted this as truth. Could we avoid adding more broken features to the language? Just saying.

(TL;DR: Just let this thread die.)


On Wed, Sep 13, 2017, 15:08 Jeremy Martin <[hidden email]> wrote:
> What am I missing?

Nothing with respect to function arguments, AFAICT.

But to beat the dead-cognitive-overhead horse again, the rules around ACI (Automatic Comma Insertion) appear to require too many exceptions. We've already covered:
  • ACI doesn't apply at all between variable declarations
  • ACI has exceptions around getter/setter properties in object literals.
I hadn't thought of these before, but there's also:
  • ACI would need exceptions in object and array literals following yield in generator functions.
  • ACI would need exceptions in object and array literals following await in async functions.
I would wager this isn't an exhaustive list yet, either.

To be clear, these aren't exceptions in the grammar itself (the ASI-style "insert comma if next token would generate a syntax error" is sufficient to handle all of these cases), but they are exceptions that developers and tooling would need to hold onto, and IMHO, relegate the purported readability improvements.

On Wed, Sep 13, 2017 at 1:55 PM, Naveen Chawla <[hidden email]> wrote:
`x` <whitespace> `[y]` would be invalid syntax, right?
So
```js
x
[y]
```
would automatically insert a comma in the case of a function call arguments list, right?

That's exactly what would be desired. What am I missing?

On Wed, 13 Sep 2017 at 20:52 Boris Zbarsky <[hidden email]> wrote:
On 9/13/17 9:57 AM, Naveen Chawla wrote:
> By this behaviour (a modification to the initial "complete statement
> produces comma" version of this proposal), everything would work
> perfectly, no?

If by "perfectly" you mean "have hard-to-predict somewhat nonlocal
behavior that makes any code relying on this a hard-to-read footgun",
then the answer might be "yes".  For pretty much any other definition of
"perfectly", I'm fairly sure the answer is "no".

> Great to hear those counter-examples as I don't know enough about ASI,

Still in the context of ASI, here are some examples of why ASI is a bad
idea:

1) What does this return?

   function f() {
     return
     5;
   }

2) What does this alert?

   var str = "hello";
   var x = str
   [x].forEach(() => alert(x))

Now back to automatic comma insertion... In your example:

   function doStuff(
       x
       y
       z
   ){
   }

if someone changes doStuff to take an array as the second arg and you
modify the call as:

   function doStuff(
       x
       [y]
       z
   ){
   }

suddenly you need to insert a comma after the "x" to preserve the right
semantics, no?  This is not terribly intuitive or obvious.  It gets even
worse in a situation like this:

   function doStuff(
       x
       /* The next argument is an array for good reasons that we
          will now expound on in a long comment, etc, etc */
       [y]
   ){
   }

Quick, tell me without testing this or looking at the spec for a while
whether this is a valid call to doStuff, with one argument, or a syntax
error that would trigger comma insertion.

But more generally, if you just use your favorite search engine on the
phrase "automatic semicolon insertion", you will get a slew of articles
explaining the pitfalls.

-Boris

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
661.312.3853
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

J Decker
In reply to this post by Boris Zbarsky
Within the context of an array or object definition I could see implementing automatic commas between elements.... but not outside; think the thread is straying a little from the original post (const isn't available in either context).  But only between completed expressions/function definitions.  
It wouldn't be horribly hard to option that into my json-6 parsing... just still don't really think I'm a fan anyway. (but that doesn't have to deal with get/set/function definitions).

On Wed, Sep 13, 2017 at 8:22 AM, Boris Zbarsky <[hidden email]> wrote:
On 9/13/17 9:57 AM, Naveen Chawla wrote:
By this behaviour (a modification to the initial "complete statement produces comma" version of this proposal), everything would work perfectly, no?

If by "perfectly" you mean "have hard-to-predict somewhat nonlocal behavior that makes any code relying on this a hard-to-read footgun", then the answer might be "yes".  For pretty much any other definition of "perfectly", I'm fairly sure the answer is "no".

Great to hear those counter-examples as I don't know enough about ASI,

Still in the context of ASI, here are some examples of why ASI is a bad idea:

1) What does this return?

  function f() {
    return
    5;
  }

2) What does this alert?

  var str = "hello";
  var x = str
  [x].forEach(() => alert(x))

Now back to automatic comma insertion... In your example:

  function doStuff(
      x
      y
      z
  ){
  }

if someone changes doStuff to take an array as the second arg and you modify the call as:

  function doStuff(
      x
      [y]
      z
  ){
  }

suddenly you need to insert a comma after the "x" to preserve the right semantics, no?  This is not terribly intuitive or obvious.  It gets even worse in a situation like this:

  function doStuff(
      x
      /* The next argument is an array for good reasons that we
         will now expound on in a long comment, etc, etc */
      [y]
  ){
  }

Quick, tell me without testing this or looking at the spec for a while whether this is a valid call to doStuff, with one argument, or a syntax error that would trigger comma insertion.

But more generally, if you just use your favorite search engine on the phrase "automatic semicolon insertion", you will get a slew of articles explaining the pitfalls.


-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Boris Zbarsky
In reply to this post by Naveen Chawla
On 9/13/17 1:55 PM, Naveen Chawla wrote:
> `x` <whitespace> `[y]` would be invalid syntax, right?

Wrong.

> What am I missing?

This is exactly why automatic X insertion with complicated rules is a
bad idea for all values of X.  ;)

-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Алексей
In reply to this post by Jeremy Martin
Thank you for good summary. If this discussion would appears in future than your mail is a great link to starts from

2017-09-13 22:08 GMT+03:00 Jeremy Martin <[hidden email]>:
> What am I missing?

Nothing with respect to function arguments, AFAICT.

But to beat the dead-cognitive-overhead horse again, the rules around ACI (Automatic Comma Insertion) appear to require too many exceptions. We've already covered:
  • ACI doesn't apply at all between variable declarations
  • ACI has exceptions around getter/setter properties in object literals.
I hadn't thought of these before, but there's also:
  • ACI would need exceptions in object and array literals following yield in generator functions.
  • ACI would need exceptions in object and array literals following await in async functions.
I would wager this isn't an exhaustive list yet, either.

To be clear, these aren't exceptions in the grammar itself (the ASI-style "insert comma if next token would generate a syntax error" is sufficient to handle all of these cases), but they are exceptions that developers and tooling would need to hold onto, and IMHO, relegate the purported readability improvements.

On Wed, Sep 13, 2017 at 1:55 PM, Naveen Chawla <[hidden email]> wrote:
`x` <whitespace> `[y]` would be invalid syntax, right?
So
```js
x
[y]
```
would automatically insert a comma in the case of a function call arguments list, right?

That's exactly what would be desired. What am I missing?

On Wed, 13 Sep 2017 at 20:52 Boris Zbarsky <[hidden email]> wrote:
On 9/13/17 9:57 AM, Naveen Chawla wrote:
> By this behaviour (a modification to the initial "complete statement
> produces comma" version of this proposal), everything would work
> perfectly, no?

If by "perfectly" you mean "have hard-to-predict somewhat nonlocal
behavior that makes any code relying on this a hard-to-read footgun",
then the answer might be "yes".  For pretty much any other definition of
"perfectly", I'm fairly sure the answer is "no".

> Great to hear those counter-examples as I don't know enough about ASI,

Still in the context of ASI, here are some examples of why ASI is a bad
idea:

1) What does this return?

   function f() {
     return
     5;
   }

2) What does this alert?

   var str = "hello";
   var x = str
   [x].forEach(() => alert(x))

Now back to automatic comma insertion... In your example:

   function doStuff(
       x
       y
       z
   ){
   }

if someone changes doStuff to take an array as the second arg and you
modify the call as:

   function doStuff(
       x
       [y]
       z
   ){
   }

suddenly you need to insert a comma after the "x" to preserve the right
semantics, no?  This is not terribly intuitive or obvious.  It gets even
worse in a situation like this:

   function doStuff(
       x
       /* The next argument is an array for good reasons that we
          will now expound on in a long comment, etc, etc */
       [y]
   ){
   }

Quick, tell me without testing this or looking at the spec for a while
whether this is a valid call to doStuff, with one argument, or a syntax
error that would trigger comma insertion.

But more generally, if you just use your favorite search engine on the
phrase "automatic semicolon insertion", you will get a slew of articles
explaining the pitfalls.

-Boris

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss




--
Jeremy Martin
<a href="tel:(661)%20312-3853" value="+16613123853" target="_blank">661.312.3853

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss



_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Allen Wirfs-Brock
In reply to this post by Tab Atkins Jr.

On Sep 13, 2017, at 12:00 PM, Tab Atkins Jr. <[hidden email]> wrote:

I believe Bob was engaging in reductio ad absurdum, Isiah. ^_^

or reductio ad FORTRAN


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Reinis Ivanovs
In reply to this post by Boris Zbarsky
The "some examples" of ASI problems might as well say "all", since there aren't more than the two listed cases worth mentioning, and even the `return` one is kind of contrived, because putting line breaks after `return` isn't usually a thing. It also doesn't follow that ASI would be a "bad idea"; remembering not to start lines with brackets or parens is easy (especially with a linter, which people should be using anyway), and the benefit is less visually noisy code and a bit less typing. The same can't be said for comma insertion, because commas aren't as noticable or often used as semicolons, and the syntax would have more 'gotchas' than with ASI, so it's just not worth it.

On Wed, Sep 13, 2017 at 6:22 PM, Boris Zbarsky <[hidden email]> wrote:
On 9/13/17 9:57 AM, Naveen Chawla wrote:
By this behaviour (a modification to the initial "complete statement produces comma" version of this proposal), everything would work perfectly, no?

If by "perfectly" you mean "have hard-to-predict somewhat nonlocal behavior that makes any code relying on this a hard-to-read footgun", then the answer might be "yes".  For pretty much any other definition of "perfectly", I'm fairly sure the answer is "no".

Great to hear those counter-examples as I don't know enough about ASI,

Still in the context of ASI, here are some examples of why ASI is a bad idea:

1) What does this return?

  function f() {
    return
    5;
  }

2) What does this alert?

  var str = "hello";
  var x = str
  [x].forEach(() => alert(x))

Now back to automatic comma insertion... In your example:

  function doStuff(
      x
      y
      z
  ){
  }

if someone changes doStuff to take an array as the second arg and you modify the call as:

  function doStuff(
      x
      [y]
      z
  ){
  }

suddenly you need to insert a comma after the "x" to preserve the right semantics, no?  This is not terribly intuitive or obvious.  It gets even worse in a situation like this:

  function doStuff(
      x
      /* The next argument is an array for good reasons that we
         will now expound on in a long comment, etc, etc */
      [y]
  ){
  }

Quick, tell me without testing this or looking at the spec for a while whether this is a valid call to doStuff, with one argument, or a syntax error that would trigger comma insertion.

But more generally, if you just use your favorite search engine on the phrase "automatic semicolon insertion", you will get a slew of articles explaining the pitfalls.


-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

Alexander Jones
IIFEs start with a (. Putting line breaks before certain expressions can help improve clarity. Your mind is made up but I have to protest. ASI *sucks*. And the extra cognitive overhead it causes is utterly pointless. If you don’t want to type them, why not program your editor to actually insert ; and a linebreak at the same time when you want to terminate a statement?

Many problems arise from parsing ambiguities — when writing code authors know exactly what they intend, why make future readers second guess?

On Fri, 15 Sep 2017 at 11:12, Reinis Ivanovs <[hidden email]> wrote:
The "some examples" of ASI problems might as well say "all", since there aren't more than the two listed cases worth mentioning, and even the `return` one is kind of contrived, because putting line breaks after `return` isn't usually a thing. It also doesn't follow that ASI would be a "bad idea"; remembering not to start lines with brackets or parens is easy (especially with a linter, which people should be using anyway), and the benefit is less visually noisy code and a bit less typing. The same can't be said for comma insertion, because commas aren't as noticable or often used as semicolons, and the syntax would have more 'gotchas' than with ASI, so it's just not worth it.

On Wed, Sep 13, 2017 at 6:22 PM, Boris Zbarsky <[hidden email]> wrote:
On 9/13/17 9:57 AM, Naveen Chawla wrote:
By this behaviour (a modification to the initial "complete statement produces comma" version of this proposal), everything would work perfectly, no?

If by "perfectly" you mean "have hard-to-predict somewhat nonlocal behavior that makes any code relying on this a hard-to-read footgun", then the answer might be "yes".  For pretty much any other definition of "perfectly", I'm fairly sure the answer is "no".

Great to hear those counter-examples as I don't know enough about ASI,

Still in the context of ASI, here are some examples of why ASI is a bad idea:

1) What does this return?

  function f() {
    return
    5;
  }

2) What does this alert?

  var str = "hello";
  var x = str
  [x].forEach(() => alert(x))

Now back to automatic comma insertion... In your example:

  function doStuff(
      x
      y
      z
  ){
  }

if someone changes doStuff to take an array as the second arg and you modify the call as:

  function doStuff(
      x
      [y]
      z
  ){
  }

suddenly you need to insert a comma after the "x" to preserve the right semantics, no?  This is not terribly intuitive or obvious.  It gets even worse in a situation like this:

  function doStuff(
      x
      /* The next argument is an array for good reasons that we
         will now expound on in a long comment, etc, etc */
      [y]
  ){
  }

Quick, tell me without testing this or looking at the spec for a while whether this is a valid call to doStuff, with one argument, or a syntax error that would trigger comma insertion.

But more generally, if you just use your favorite search engine on the phrase "automatic semicolon insertion", you will get a slew of articles explaining the pitfalls.


-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Make comma at the end of line optional

kai zhu
-1 for code-maintainability.
i don’t see the benefits justifying the extra complexity and rules it adds to javascript style-guides and linters (and those who follow them).

On Sep 26, 2017, at 3:27 AM, Alexander Jones <[hidden email]> wrote:

IIFEs start with a (. Putting line breaks before certain expressions can help improve clarity. Your mind is made up but I have to protest. ASI *sucks*. And the extra cognitive overhead it causes is utterly pointless. If you don’t want to type them, why not program your editor to actually insert ; and a linebreak at the same time when you want to terminate a statement?

Many problems arise from parsing ambiguities — when writing code authors know exactly what they intend, why make future readers second guess?

On Fri, 15 Sep 2017 at 11:12, Reinis Ivanovs <[hidden email]> wrote:
The "some examples" of ASI problems might as well say "all", since there aren't more than the two listed cases worth mentioning, and even the `return` one is kind of contrived, because putting line breaks after `return` isn't usually a thing. It also doesn't follow that ASI would be a "bad idea"; remembering not to start lines with brackets or parens is easy (especially with a linter, which people should be using anyway), and the benefit is less visually noisy code and a bit less typing. The same can't be said for comma insertion, because commas aren't as noticable or often used as semicolons, and the syntax would have more 'gotchas' than with ASI, so it's just not worth it.

On Wed, Sep 13, 2017 at 6:22 PM, Boris Zbarsky <[hidden email]> wrote:
On 9/13/17 9:57 AM, Naveen Chawla wrote:
By this behaviour (a modification to the initial "complete statement produces comma" version of this proposal), everything would work perfectly, no?

If by "perfectly" you mean "have hard-to-predict somewhat nonlocal behavior that makes any code relying on this a hard-to-read footgun", then the answer might be "yes".  For pretty much any other definition of "perfectly", I'm fairly sure the answer is "no".

Great to hear those counter-examples as I don't know enough about ASI,

Still in the context of ASI, here are some examples of why ASI is a bad idea:

1) What does this return?

  function f() {
    return
    5;
  }

2) What does this alert?

  var str = "hello";
  var x = str
  [x].forEach(() => alert(x))

Now back to automatic comma insertion... In your example:

  function doStuff(
      x
      y
      z
  ){
  }

if someone changes doStuff to take an array as the second arg and you modify the call as:

  function doStuff(
      x
      [y]
      z
  ){
  }

suddenly you need to insert a comma after the "x" to preserve the right semantics, no?  This is not terribly intuitive or obvious.  It gets even worse in a situation like this:

  function doStuff(
      x
      /* The next argument is an array for good reasons that we
         will now expound on in a long comment, etc, etc */
      [y]
  ){
  }

Quick, tell me without testing this or looking at the spec for a while whether this is a valid call to doStuff, with one argument, or a syntax error that would trigger comma insertion.

But more generally, if you just use your favorite search engine on the phrase "automatic semicolon insertion", you will get a slew of articles explaining the pitfalls.


-Boris
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
123