Re: Make comma at the end of line optional

[Allen Wirfs-Brock]

> On Sep 13, 2017, at 12:00 PM, Tab Atkins Jr.  wrote:
> 
> I believe Bob was engaging in reductio ad absurdum, Isiah. ^_^

or reductio ad FORTRAN

___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[Алексей]

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 :

> *> 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 
> wrote:
>
>> `x`  `[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  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
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853 <(661)%20312-3853>
> @jmar777  / @j 
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[Boris Zbarsky]

On 9/13/17 1:55 PM, Naveen Chawla wrote:

`x`  `[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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[J Decker]

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

Re: Make comma at the end of line optional

[Isiah Meadows]

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  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 
> wrote:
>
>> `x`  `[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  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
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853
> @jmar777  / @j 
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[Jeremy Martin]

*> 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 
wrote:

> `x`  `[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  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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Jeremy Martin
661.312.3853
@jmar777  / @j 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[Isiah Meadows]

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.  wrote:

> I believe Bob was engaging in reductio ad absurdum, Isiah. ^_^
>
> On Wed, Sep 13, 2017 at 11:51 AM, Isiah Meadows 
> 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  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 
> >> wrote:
> >>>
> >>> `x`  `[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
> >> es-discuss@mozilla.org
> >> https://mail.mozilla.org/listinfo/es-discuss
> >
> >
> > ___
> > es-discuss mailing list
> > es-discuss@mozilla.org
> > https://mail.mozilla.org/listinfo/es-discuss
> >
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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  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  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 
>> wrote:
>>>
>>> `x`  `[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
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[Isiah Meadows]

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  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 
> wrote:
>
>> `x`  `[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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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 
wrote:

> `x`  `[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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[Naveen Chawla]

`x`  `[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  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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[Boris Zbarsky]

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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional (Naveen Chawla)

[T.J. Crowder]

On Wed, Sep 13, 2017 at 3:52 PM, Aluan Haddad  wrote:
>
> ...given the countless hours already wasted debating semicolon
> usage, and with the inherent complexity that this would add to
> tools like transpilers and minifiers, this would seem to add
> negative value.

^^ this. I've been trying to phrase it for a while now. Well put.

It's useful to remember that JavaScript engines are not the only consumers
of JavaScript source code. Linters, transpilers, syntax highlighters, code
introspection and refactoring tools, etc., etc., etc. -- they all have
their cages rattled by syntax changes. The more complex the syntax (and
this would have to be quite complex in a world of class fields, private
data, etc.), the more the cages are rattled.

Humans, too, are consumers of JavaScript source code. We're clever, but
adding to the cognitive load needs a good justification.

For me, the cost/benefit on this optional commas thing is just nowhere near
a sell.

-- T.J. Crowder
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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 :

> 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 
> 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  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
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
> Jeremy Martin
> 661.312.3853 <(661)%20312-3853>
> @jmar777  / @j 
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

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


-- 
Jeremy Martin
661.312.3853
@jmar777  / @j 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional (Naveen Chawla)

[Aluan Haddad]

I can see an argument for this by analogy with class syntax but I for one
would immediately go looking for a linter which raised errors for these
omitted commas.

Furthermore, given the countless hours already wasted debating semicolon
usage, and with the inherent complexity that this would add to tools like
transpilers and minifiers, this would seem to add negative value.

On Sep 13, 2017 10:32 AM,  wrote:

> Send es-discuss mailing list submissions to
> es-discuss@mozilla.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://mail.mozilla.org/listinfo/es-discuss
> or, via email, send a message with subject or body 'help' to
> es-discuss-requ...@mozilla.org
>
> You can reach the person managing the list at
> es-discuss-ow...@mozilla.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of es-discuss digest..."
>
> Today's Topics:
>
>1. Re: Make comma at the end of line optional (Naveen Chawla)
>2. Re: Lazy evaluation (Andrea Giammarchi)
>
>
> -- Forwarded message --
> From: Naveen Chawla 
> To: Boris Zbarsky , es-discuss@mozilla.org
> Cc:
> Bcc:
> Date: Wed, 13 Sep 2017 13:57:01 +
> Subject: Re: Make comma at the end of line optional
> 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  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
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> -- Forwarded message --
> From: Andrea Giammarchi 
> To: Alex Kodat 
> Cc: "es-discuss@mozilla.org" 
> Bcc:
> Date: Wed, 13 Sep 2017 16:32:28 +0200
> Subject: Re: Lazy evaluation
> > Maybe you mean "will behave more or less as if (except more
> efficiently)"?
>
> no, I meant: it will transpiled into something using private WeakMaps.
>
> I don't have any interest in talk nanoseconds for something unrelated to
> the topic though.
>
> Best Regards
>
> On Wed, Sep 13, 2017 at 1:54 PM, Alex Kodat  wrote:
>
>> What do you mean by “will be transpiled through”? My understanding of the
>> private property proposal is that private properties will be in fixed slots
>> (inaccessible outside the class) in the object so there would be no
>> WeakMap. Maybe you mean "will behave more or less as if (except more
>> efficiently)"?
>>
>> 
>> Alex Kodat
>>
>> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
>> Andrea Giammarchi
>> Sent: Wednesday, September 13, 2017 2:31 AM
>> To: Steve Fink 
>> Cc: es-discuss@mozilla.org
>> Subject: Re: Lazy evaluation
>>
>> > The properties already existed, so defineProperty shouldn't modify the
>> order IIUC
>>
>> well, nope. the property existed in the prototype, not in the object.
>>
>> anyway, I guess private properties, that are a possible solution, will be
>> transpiled through a WeakMap so that most likely anything discussed in here
>> won't make sense and the future code would look like the following
>>
>> ```js
>> class A {
>>   #random;
>>   get random() {
>> return this.#random ||
>>   (this.#random = Math.random());
>>   }
>> }
>>
>>
>> // transpiled
>> var A = function (wm) {
>>   function A() {
>> wm.set(this, {random: void 0});
>>   }
>>   Object.defineProperties(
>> A.prototype,
>> {
>>   random: {
>> configurable: true,
>> get: function () {
>>   return wm.get(this).random ||
>> 

Re: Make comma at the end of line optional (Naveen Chawla)

[Aluan Haddad]

I can see the argument for this by analogy with class syntax but

On Sep 13, 2017 10:32 AM,  wrote:

Send es-discuss mailing list submissions to
es-discuss@mozilla.org

To subscribe or unsubscribe via the World Wide Web, visit
https://mail.mozilla.org/listinfo/es-discuss
or, via email, send a message with subject or body 'help' to
es-discuss-requ...@mozilla.org

You can reach the person managing the list at
es-discuss-ow...@mozilla.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of es-discuss digest..."

Today's Topics:

   1. Re: Make comma at the end of line optional (Naveen Chawla)
   2. Re: Lazy evaluation (Andrea Giammarchi)


-- Forwarded message --
From: Naveen Chawla 
To: Boris Zbarsky , es-discuss@mozilla.org
Cc:
Bcc:
Date: Wed, 13 Sep 2017 13:57:01 +
Subject: Re: Make comma at the end of line optional
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  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
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


-- Forwarded message --
From: Andrea Giammarchi 
To: Alex Kodat 
Cc: "es-discuss@mozilla.org" 
Bcc:
Date: Wed, 13 Sep 2017 16:32:28 +0200
Subject: Re: Lazy evaluation
> Maybe you mean "will behave more or less as if (except more efficiently)"?

no, I meant: it will transpiled into something using private WeakMaps.

I don't have any interest in talk nanoseconds for something unrelated to
the topic though.

Best Regards

On Wed, Sep 13, 2017 at 1:54 PM, Alex Kodat  wrote:

> What do you mean by “will be transpiled through”? My understanding of the
> private property proposal is that private properties will be in fixed slots
> (inaccessible outside the class) in the object so there would be no
> WeakMap. Maybe you mean "will behave more or less as if (except more
> efficiently)"?
>
> 
> Alex Kodat
>
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Andrea Giammarchi
> Sent: Wednesday, September 13, 2017 2:31 AM
> To: Steve Fink 
> Cc: es-discuss@mozilla.org
> Subject: Re: Lazy evaluation
>
> > The properties already existed, so defineProperty shouldn't modify the
> order IIUC
>
> well, nope. the property existed in the prototype, not in the object.
>
> anyway, I guess private properties, that are a possible solution, will be
> transpiled through a WeakMap so that most likely anything discussed in here
> won't make sense and the future code would look like the following
>
> ```js
> class A {
>   #random;
>   get random() {
> return this.#random ||
>   (this.#random = Math.random());
>   }
> }
>
>
> // transpiled
> var A = function (wm) {
>   function A() {
> wm.set(this, {random: void 0});
>   }
>   Object.defineProperties(
> A.prototype,
> {
>   random: {
> configurable: true,
> get: function () {
>   return wm.get(this).random ||
> (wm.get(this).random = Math.random());
> }
>   }
> }
>   );
>   return A;
> }(new WeakMap);
> ```
>
>
>
>
>
>
> On Tue, Sep 12, 2017 at 10:39 PM, Steve Fink 
> wrote:
> My intent was only to respond to the performance analysis, specifically
> the implication that the only performance cost is in building the new
> hidden class. That is not the case; everything that touches those objects
> is affected as well.
>
> Whether or not it's still the right way to accomplish what you're 

Re: Lazy evaluation

[Andrea Giammarchi]

> Maybe you mean "will behave more or less as if (except more efficiently)"?

no, I meant: it will transpiled into something using private WeakMaps.

I don't have any interest in talk nanoseconds for something unrelated to
the topic though.

Best Regards

On Wed, Sep 13, 2017 at 1:54 PM, Alex Kodat  wrote:

> What do you mean by “will be transpiled through”? My understanding of the
> private property proposal is that private properties will be in fixed slots
> (inaccessible outside the class) in the object so there would be no
> WeakMap. Maybe you mean "will behave more or less as if (except more
> efficiently)"?
>
> 
> Alex Kodat
>
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Andrea Giammarchi
> Sent: Wednesday, September 13, 2017 2:31 AM
> To: Steve Fink 
> Cc: es-discuss@mozilla.org
> Subject: Re: Lazy evaluation
>
> > The properties already existed, so defineProperty shouldn't modify the
> order IIUC
>
> well, nope. the property existed in the prototype, not in the object.
>
> anyway, I guess private properties, that are a possible solution, will be
> transpiled through a WeakMap so that most likely anything discussed in here
> won't make sense and the future code would look like the following
>
> ```js
> class A {
>   #random;
>   get random() {
> return this.#random ||
>   (this.#random = Math.random());
>   }
> }
>
>
> // transpiled
> var A = function (wm) {
>   function A() {
> wm.set(this, {random: void 0});
>   }
>   Object.defineProperties(
> A.prototype,
> {
>   random: {
> configurable: true,
> get: function () {
>   return wm.get(this).random ||
> (wm.get(this).random = Math.random());
> }
>   }
> }
>   );
>   return A;
> }(new WeakMap);
> ```
>
>
>
>
>
>
> On Tue, Sep 12, 2017 at 10:39 PM, Steve Fink 
> wrote:
> My intent was only to respond to the performance analysis, specifically
> the implication that the only performance cost is in building the new
> hidden class. That is not the case; everything that touches those objects
> is affected as well.
>
> Whether or not it's still the right way to accomplish what you're after, I
> wasn't venturing an opinion. I could probably come up with a benchmark
> showing that your WeakMap approach can be faster -- eg by only accessing
> the property once, but feeding the old and new versions of the object into
> code that executes many many many times (doing something that never looks
> at that property, but is now slightly slower because it isn't monomorphic).
> But I suspect that for practical usage, redefining the property *is* faster
> than a WeakMap.
>
> If I were to look beyond for other solutions for your problem, then I'm
> just speculating. Can decorators populate multiple properties once the
> expensive work is done?
>
> I really want to tell the VM what's going on. I guess if it knew that
> accessing a getter property would convert it into a value property, and
> that it was doing something that would access the getter, then it could
> know to use the outgoing shape instead of the incoming shape. If only it
> knew that the getter was pure... but that way lies madness.
>
> Given that most code that would slow down would also trigger the lazy
> defineProperty(), it's really not going to be that much of an issue. Any
> access after the first will see a single shape.
>
> meh. Just take the perf hit, with awareness that you may be triggering
> slight slowdowns in all users of that object. Or you might not. I doubt
> it'll be that big, since you'll probably just end up with an inline cache
> for both shapes and there won't be all that much to optimize based on
> knowing a single shape.
>
> Oh, and I think I was wrong about property enumeration order. The
> properties already existed, so defineProperty shouldn't modify the order
> IIUC. (I am awful with language semantics.)
>
> On 9/11/17 2:48 PM, Andrea Giammarchi wrote:
> Steve it's not solved in any other way. Even if you use a WeakMap with an
> object, you gonna lazy attach properties to that object.
>
> I honestly would like to see alternatives, if any, 'cause so far there is
> a benchmark and it proves already lazy property assignment is around 4x
> faster.
>
> So, it's easy to say "it's not the best approach" but apparently hard to
> prove that's the case?
>
> Looking forward to see better alternatives.
>
>
> On Mon, Sep 11, 2017 at 8:15 PM, Steve Fink 
> wrote:
> On 9/11/17 5:36 AM, Matthew Robb wrote:
> > I think it's irrelevant if internally VMs are not too happy. VMs are
> there to solve our problems, not vice-versa ;-)
> ​
> This ^​ is very important for everyone to get on board with. Regardless
> the cost should be negligible as the shape is only changing at the point of
> delayed init. This will cause, for example V8, to deop the object and have
> to build a new hidden class but 

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

Re: Lazy evaluation

[Isiah Meadows]

Nit: `_` is a very valid identifier. (Consider Underscore/Lodash)

On Wed, Sep 13, 2017, 09:32 Alex Kodat  wrote:

> Also, FWIW,  since we’re talking about nanoseconds of performance, here, I
> think slightly better than:
>
> return this.#random || (this.#random = Math.random());
>
> Is
>
> return (this.#random === undefined) ? this.#random = Math.random() :
> this.#random;
>
> This is because in the former, the compiled code has to determine whether
> this.#random is coercible into a Boolean. At the very least, it has to do
> an "Is this an object and, if so, not undefined ==> true" test. From first
> principles, the ternary expression is going to be more efficient. It simply
> checks if the value at this.#random is the same as the global undefined
> value and, if not, returns that value. No extra tests necessary.
>
> And at least with V8 theory == practice in this case (at least in all my
> tests). And yes, we're talking nanosecond here.
>
> While this looks a bit like the null propagation operator would be
> applicable, it's really not.
>
> Also FWIW, if you get tired of seeing/typing undefined, we add _ to the
> global object which means the above can be written as:
>
> return (this.#random === _) ? this.#random = Math.random() :
> this.#random;
>
> You might think that this would perform worse than the undefined but, in
> fact, for V8 it's identical -- undefined and _ are both just properties of
> the global object. I think this reads especially well in function calls
> where you want an undefined placeholder
>
>   fooey(_, "whatever");
>
> Visually, _ just says undefined to me.
>
> 
> Alex Kodat
>
> From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of
> Andrea Giammarchi
> Sent: Wednesday, September 13, 2017 2:31 AM
> To: Steve Fink 
> Cc: es-discuss@mozilla.org
> Subject: Re: Lazy evaluation
>
> > The properties already existed, so defineProperty shouldn't modify the
> order IIUC
>
> well, nope. the property existed in the prototype, not in the object.
>
> anyway, I guess private properties, that are a possible solution, will be
> transpiled through a WeakMap so that most likely anything discussed in here
> won't make sense and the future code would look like the following
>
> ```js
> class A {
>   #random;
>   get random() {
> return this.#random ||
>   (this.#random = Math.random());
>   }
> }
>
>
> // transpiled
> var A = function (wm) {
>   function A() {
> wm.set(this, {random: void 0});
>   }
>   Object.defineProperties(
> A.prototype,
> {
>   random: {
> configurable: true,
> get: function () {
>   return wm.get(this).random ||
> (wm.get(this).random = Math.random());
> }
>   }
> }
>   );
>   return A;
> }(new WeakMap);
> ```
>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Lazy evaluation

[Alex Kodat]

Also, FWIW,  since we’re talking about nanoseconds of performance, here, I 
think slightly better than:

return this.#random || (this.#random = Math.random());

Is

return (this.#random === undefined) ? this.#random = Math.random() : 
this.#random;

This is because in the former, the compiled code has to determine whether 
this.#random is coercible into a Boolean. At the very least, it has to do an 
"Is this an object and, if so, not undefined ==> true" test. From first 
principles, the ternary expression is going to be more efficient. It simply 
checks if the value at this.#random is the same as the global undefined value 
and, if not, returns that value. No extra tests necessary.

And at least with V8 theory == practice in this case (at least in all my 
tests). And yes, we're talking nanosecond here.

While this looks a bit like the null propagation operator would be applicable, 
it's really not. 

Also FWIW, if you get tired of seeing/typing undefined, we add _ to the global 
object which means the above can be written as:

return (this.#random === _) ? this.#random = Math.random() : this.#random;

You might think that this would perform worse than the undefined but, in fact, 
for V8 it's identical -- undefined and _ are both just properties of the global 
object. I think this reads especially well in function calls where you want an 
undefined placeholder

  fooey(_, "whatever");

Visually, _ just says undefined to me.


Alex Kodat

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Andrea 
Giammarchi
Sent: Wednesday, September 13, 2017 2:31 AM
To: Steve Fink 
Cc: es-discuss@mozilla.org
Subject: Re: Lazy evaluation

> The properties already existed, so defineProperty shouldn't modify the order 
> IIUC

well, nope. the property existed in the prototype, not in the object.

anyway, I guess private properties, that are a possible solution, will be 
transpiled through a WeakMap so that most likely anything discussed in here 
won't make sense and the future code would look like the following

```js
class A {
  #random;
  get random() {
return this.#random ||
  (this.#random = Math.random());
  }
}


// transpiled
var A = function (wm) {
  function A() {
wm.set(this, {random: void 0});
  }
  Object.defineProperties(
A.prototype,
{
  random: {
configurable: true,
get: function () {
  return wm.get(this).random ||
(wm.get(this).random = Math.random());
}
  }
}
  );
  return A;
}(new WeakMap);
```



___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Make comma at the end of line optional

[Jeremy Martin]

*> Can someone remind me of the problem doing it this way, if any? (I'm not
sure it has been mentioned yet)*

The problem is in how this proposal has currently been structured:

*> [...] if line is a complete statement and next line is not an operator
than consider it as complete argument (field, element) declaration.*

In the provided example...

```js
{
get
x() //valid syntax after "get", so no comma inserted
}
```

... the `get` line is a valid, complete shorthand property declaration, so
a comma would be inserted, and thus changing the semantics of already valid
code.

As is the case with virtually all potential syntax ambiguities, this can be
worked around through exceptions and extra rules regarding when commas
are/aren't inserted, but that tends this proposal towards the same
idiosyncratic footguns that come with ASI.

This is obviously a subjective analysis, but this proposal seems to
introduce too much wtfjs material in exchange for too little in
time/character savings.


On Wed, Sep 13, 2017 at 9:05 AM, Naveen Chawla 
wrote:

> Very interesting point. Is there another way to get this optional comma
> proposal through while being backwards compatible? I really like the idea.
>
> If it worked like ASI, then surely it would allow the multi-line `get`
> case?:
>
> ```js
> {
> get
> x() //valid syntax after "get", so no comma inserted
> }
> ```
>
> Can someone remind me of the problem doing it this way, if any? (I'm not
> sure it has been mentioned yet)
>
>
>
> On Wed, 13 Sep 2017 at 18:11 Isiah Meadows  wrote:
>
>> I can assure you that will likely never happen, because it's a pretty
>> obvious identifier to use in more generic or high-context scenarios.
>> (Think: `get(foo, bar)`, and I've done that plenty of times.)
>>
>> On Wed, Sep 13, 2017, 03:05 Naveen Chawla  wrote:
>>
>>> Can't `get` be relegated to a reserved/keyword, like `let`, `yield` and
>>> `await` were? Just curious about that kind of process & decision?...
>>>
>>> On Wed, 13 Sep 2017 at 05:25 Matthew Robb 
>>> wrote:
>>>
 Okay what would be the cons to allowing semi colons in place of commas
 in object literals?

 I have an aversion to dangling commas. They're like,

 On Sep 12, 2017 7:40 PM, "Jordan Harband"  wrote:

> I would take commas over a mixture a thousand times over; I'd do the
> same with semicolons - it's not the presence or absence of these tokens
> that causes a problem, it's the ambiguity.
>
> Introducing the same horrific ambiguity around semicolons, for commas,
> does not sound like a good idea.
>
> On Tue, Sep 12, 2017 at 1:57 PM, Tab Atkins Jr. 
> wrote:
>
>> On Tue, Sep 12, 2017 at 1:49 PM, Алексей  wrote:
>> > Think of it from a different way: if there would be no ',' how
>> would you
>> > react on the idea of adding it? Peaty sour every one would decide
>> that would
>> > be a complete nonsense.
>>
>> This sort of hypothetical isn't useful; you're not proposing switching
>> over to *solely* comma-less, you're proposing a *mixture* of comma and
>> comma-less being allowed.  That has very different ergonomics than
>> either all-comma or all-comma-less.
>>
>> The hypothetical comma-less language would also have made many
>> different syntax decisions over the years to accommodate that, which
>> current JS has *not* made.  This causes the sorts of problems that
>> Claude/etc have pointed out.
>>
>> ~TJ
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>


-- 
Jeremy Martin
661.312.3853
@jmar777  / @j 
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Make comma at the end of line optional

[Boris Zbarsky]

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
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Make comma at the end of line optional

[Naveen Chawla]

Very interesting point. Is there another way to get this optional comma
proposal through while being backwards compatible? I really like the idea.

If it worked like ASI, then surely it would allow the multi-line `get`
case?:

```js
{
get
x() //valid syntax after "get", so no comma inserted
}
```

Can someone remind me of the problem doing it this way, if any? (I'm not
sure it has been mentioned yet)



On Wed, 13 Sep 2017 at 18:11 Isiah Meadows  wrote:

> I can assure you that will likely never happen, because it's a pretty
> obvious identifier to use in more generic or high-context scenarios.
> (Think: `get(foo, bar)`, and I've done that plenty of times.)
>
> On Wed, Sep 13, 2017, 03:05 Naveen Chawla  wrote:
>
>> Can't `get` be relegated to a reserved/keyword, like `let`, `yield` and
>> `await` were? Just curious about that kind of process & decision?...
>>
>> On Wed, 13 Sep 2017 at 05:25 Matthew Robb  wrote:
>>
>>> Okay what would be the cons to allowing semi colons in place of commas
>>> in object literals?
>>>
>>> I have an aversion to dangling commas. They're like,
>>>
>>> On Sep 12, 2017 7:40 PM, "Jordan Harband"  wrote:
>>>
 I would take commas over a mixture a thousand times over; I'd do the
 same with semicolons - it's not the presence or absence of these tokens
 that causes a problem, it's the ambiguity.

 Introducing the same horrific ambiguity around semicolons, for commas,
 does not sound like a good idea.

 On Tue, Sep 12, 2017 at 1:57 PM, Tab Atkins Jr. 
 wrote:

> On Tue, Sep 12, 2017 at 1:49 PM, Алексей  wrote:
> > Think of it from a different way: if there would be no ',' how would
> you
> > react on the idea of adding it? Peaty sour every one would decide
> that would
> > be a complete nonsense.
>
> This sort of hypothetical isn't useful; you're not proposing switching
> over to *solely* comma-less, you're proposing a *mixture* of comma and
> comma-less being allowed.  That has very different ergonomics than
> either all-comma or all-comma-less.
>
> The hypothetical comma-less language would also have made many
> different syntax decisions over the years to accommodate that, which
> current JS has *not* made.  This causes the sorts of problems that
> Claude/etc have pointed out.
>
> ~TJ
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

 ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Re: Make comma at the end of line optional

[Isiah Meadows]

I can assure you that will likely never happen, because it's a pretty
obvious identifier to use in more generic or high-context scenarios.
(Think: `get(foo, bar)`, and I've done that plenty of times.)

On Wed, Sep 13, 2017, 03:05 Naveen Chawla  wrote:

> Can't `get` be relegated to a reserved/keyword, like `let`, `yield` and
> `await` were? Just curious about that kind of process & decision?...
>
> On Wed, 13 Sep 2017 at 05:25 Matthew Robb  wrote:
>
>> Okay what would be the cons to allowing semi colons in place of commas in
>> object literals?
>>
>> I have an aversion to dangling commas. They're like,
>>
>> On Sep 12, 2017 7:40 PM, "Jordan Harband"  wrote:
>>
>>> I would take commas over a mixture a thousand times over; I'd do the
>>> same with semicolons - it's not the presence or absence of these tokens
>>> that causes a problem, it's the ambiguity.
>>>
>>> Introducing the same horrific ambiguity around semicolons, for commas,
>>> does not sound like a good idea.
>>>
>>> On Tue, Sep 12, 2017 at 1:57 PM, Tab Atkins Jr. 
>>> wrote:
>>>
 On Tue, Sep 12, 2017 at 1:49 PM, Алексей  wrote:
 > Think of it from a different way: if there would be no ',' how would
 you
 > react on the idea of adding it? Peaty sour every one would decide
 that would
 > be a complete nonsense.

 This sort of hypothetical isn't useful; you're not proposing switching
 over to *solely* comma-less, you're proposing a *mixture* of comma and
 comma-less being allowed.  That has very different ergonomics than
 either all-comma or all-comma-less.

 The hypothetical comma-less language would also have made many
 different syntax decisions over the years to accommodate that, which
 current JS has *not* made.  This causes the sorts of problems that
 Claude/etc have pointed out.

 ~TJ
 ___
 es-discuss mailing list
 es-discuss@mozilla.org
 https://mail.mozilla.org/listinfo/es-discuss

>>>
>>>
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

RE: Lazy evaluation

[Alex Kodat]

What do you mean by “will be transpiled through”? My understanding of the 
private property proposal is that private properties will be in fixed slots 
(inaccessible outside the class) in the object so there would be no WeakMap. 
Maybe you mean "will behave more or less as if (except more efficiently)"?


Alex Kodat

From: es-discuss [mailto:es-discuss-boun...@mozilla.org] On Behalf Of Andrea 
Giammarchi
Sent: Wednesday, September 13, 2017 2:31 AM
To: Steve Fink 
Cc: es-discuss@mozilla.org
Subject: Re: Lazy evaluation

> The properties already existed, so defineProperty shouldn't modify the order 
> IIUC

well, nope. the property existed in the prototype, not in the object.

anyway, I guess private properties, that are a possible solution, will be 
transpiled through a WeakMap so that most likely anything discussed in here 
won't make sense and the future code would look like the following

```js
class A {
  #random;
  get random() {
return this.#random ||
  (this.#random = Math.random());
  }
}


// transpiled
var A = function (wm) {
  function A() {
wm.set(this, {random: void 0});
  }
  Object.defineProperties(
A.prototype,
{
  random: {
configurable: true,
get: function () {
  return wm.get(this).random ||
(wm.get(this).random = Math.random());
}
  }
}
  );
  return A;
}(new WeakMap);
```






On Tue, Sep 12, 2017 at 10:39 PM, Steve Fink  wrote:
My intent was only to respond to the performance analysis, specifically the 
implication that the only performance cost is in building the new hidden class. 
That is not the case; everything that touches those objects is affected as well.

Whether or not it's still the right way to accomplish what you're after, I 
wasn't venturing an opinion. I could probably come up with a benchmark showing 
that your WeakMap approach can be faster -- eg by only accessing the property 
once, but feeding the old and new versions of the object into code that 
executes many many many times (doing something that never looks at that 
property, but is now slightly slower because it isn't monomorphic). But I 
suspect that for practical usage, redefining the property *is* faster than a 
WeakMap.

If I were to look beyond for other solutions for your problem, then I'm just 
speculating. Can decorators populate multiple properties once the expensive 
work is done?

I really want to tell the VM what's going on. I guess if it knew that accessing 
a getter property would convert it into a value property, and that it was doing 
something that would access the getter, then it could know to use the outgoing 
shape instead of the incoming shape. If only it knew that the getter was 
pure... but that way lies madness.

Given that most code that would slow down would also trigger the lazy 
defineProperty(), it's really not going to be that much of an issue. Any access 
after the first will see a single shape.

meh. Just take the perf hit, with awareness that you may be triggering slight 
slowdowns in all users of that object. Or you might not. I doubt it'll be that 
big, since you'll probably just end up with an inline cache for both shapes and 
there won't be all that much to optimize based on knowing a single shape.

Oh, and I think I was wrong about property enumeration order. The properties 
already existed, so defineProperty shouldn't modify the order IIUC. (I am awful 
with language semantics.)

On 9/11/17 2:48 PM, Andrea Giammarchi wrote:
Steve it's not solved in any other way. Even if you use a WeakMap with an 
object, you gonna lazy attach properties to that object. 

I honestly would like to see alternatives, if any, 'cause so far there is a 
benchmark and it proves already lazy property assignment is around 4x faster.

So, it's easy to say "it's not the best approach" but apparently hard to prove 
that's the case?

Looking forward to see better alternatives.


On Mon, Sep 11, 2017 at 8:15 PM, Steve Fink  wrote:
On 9/11/17 5:36 AM, Matthew Robb wrote:
> I think it's irrelevant if internally VMs are not too happy. VMs are there to 
> solve our problems, not vice-versa ;-)
​
This ^​ is very important for everyone to get on board with. Regardless the 
cost should be negligible as the shape is only changing at the point of delayed 
init. This will cause, for example V8, to deop the object and have to build a 
new hidden class but only the one time. I guess it would potentially be 
interesting to support an own property that when undefined would delegate up 
the proto chain.

(I don't know, but) I would expect it to be worse than this. The shape is 
changing at the point of delayed init, which means that if an engine is 
associating the possible set of shapes with the constructor (or some other form 
of allocation site + mandatory initialization), then that site will produce 
multiple shapes. All code using such objects, if they ever see 

Re: Lazy evaluation

[Andrea Giammarchi]

> The properties already existed, so defineProperty shouldn't modify the
order IIUC

well, nope. the property existed in the prototype, not in the object.

anyway, I guess private properties, that are a possible solution, will be
transpiled through a WeakMap so that most likely anything discussed in here
won't make sense and the future code would look like the following

```js
class A {
  #random;
  get random() {
return this.#random ||
  (this.#random = Math.random());
  }
}


// transpiled
var A = function (wm) {
  function A() {
wm.set(this, {random: void 0});
  }
  Object.defineProperties(
A.prototype,
{
  random: {
configurable: true,
get: function () {
  return wm.get(this).random ||
(wm.get(this).random = Math.random());
}
  }
}
  );
  return A;
}(new WeakMap);
```






On Tue, Sep 12, 2017 at 10:39 PM, Steve Fink  wrote:

> My intent was only to respond to the performance analysis, specifically
> the implication that the only performance cost is in building the new
> hidden class. That is not the case; everything that touches those objects
> is affected as well.
>
> Whether or not it's still the right way to accomplish what you're after, I
> wasn't venturing an opinion. I could probably come up with a benchmark
> showing that your WeakMap approach can be faster -- eg by only accessing
> the property once, but feeding the old and new versions of the object into
> code that executes many many many times (doing something that never looks
> at that property, but is now slightly slower because it isn't monomorphic).
> But I suspect that for practical usage, redefining the property *is* faster
> than a WeakMap.
>
> If I were to look beyond for other solutions for your problem, then I'm
> just speculating. Can decorators populate multiple properties once the
> expensive work is done?
>
> I really want to tell the VM what's going on. I guess if it knew that
> accessing a getter property would convert it into a value property, and
> that it was doing something that would access the getter, then it could
> know to use the outgoing shape instead of the incoming shape. If only it
> knew that the getter was pure... but that way lies madness.
>
> Given that most code that would slow down would also trigger the lazy
> defineProperty(), it's really not going to be that much of an issue. Any
> access after the first will see a single shape.
>
> meh. Just take the perf hit, with awareness that you may be triggering
> slight slowdowns in all users of that object. Or you might not. I doubt
> it'll be that big, since you'll probably just end up with an inline cache
> for both shapes and there won't be all that much to optimize based on
> knowing a single shape.
>
> Oh, and I think I was wrong about property enumeration order. The
> properties already existed, so defineProperty shouldn't modify the order
> IIUC. (I am awful with language semantics.)
>
> On 9/11/17 2:48 PM, Andrea Giammarchi wrote:
>
> Steve it's not solved in any other way. Even if you use a WeakMap with an
> object, you gonna lazy attach properties to that object.
>
> I honestly would like to see alternatives, if any, 'cause so far there is
> a benchmark and it proves already lazy property assignment is around 4x
> faster.
>
> So, it's easy to say "it's not the best approach" but apparently hard to
> prove that's the case?
>
> Looking forward to see better alternatives.
>
>
> On Mon, Sep 11, 2017 at 8:15 PM, Steve Fink  wrote:
>
>> On 9/11/17 5:36 AM, Matthew Robb wrote:
>>
>> > I think it's irrelevant if internally VMs are not too happy. VMs are
>> there to solve our problems, not vice-versa ;-)
>> ​
>> This ^​ is very important for everyone to get on board with. Regardless
>> the cost should be negligible as the shape is only changing at the point of
>> delayed init. This will cause, for example V8, to deop the object and have
>> to build a new hidden class but only the one time. I guess it would
>> potentially be interesting to support an own property that when undefined
>> would delegate up the proto chain.
>>
>>
>> (I don't know, but) I would expect it to be worse than this. The shape is
>> changing at the point of delayed init, which means that if an engine is
>> associating the possible set of shapes with the constructor (or some other
>> form of allocation site + mandatory initialization), then that site will
>> produce multiple shapes. All code using such objects, if they ever see both
>> shapes, will have to handle them both. Even worse, if you have several of
>> these delayed init properties and you end up lazily initializing them in
>> different orders (which seems relatively easy to do), then the internal
>> slot offsets will vary.
>>
>> You don't need to bend over backwards to make things easy for the VMs,
>> but you don't want to be mean to them either. :-)
>>
>> Not to mention that the observable property iteration 

Re: Re: Make comma at the end of line optional

[Naveen Chawla]

Can't `get` be relegated to a reserved/keyword, like `let`, `yield` and
`await` were? Just curious about that kind of process & decision?...

On Wed, 13 Sep 2017 at 05:25 Matthew Robb  wrote:

> Okay what would be the cons to allowing semi colons in place of commas in
> object literals?
>
> I have an aversion to dangling commas. They're like,
>
> On Sep 12, 2017 7:40 PM, "Jordan Harband"  wrote:
>
>> I would take commas over a mixture a thousand times over; I'd do the same
>> with semicolons - it's not the presence or absence of these tokens that
>> causes a problem, it's the ambiguity.
>>
>> Introducing the same horrific ambiguity around semicolons, for commas,
>> does not sound like a good idea.
>>
>> On Tue, Sep 12, 2017 at 1:57 PM, Tab Atkins Jr. 
>> wrote:
>>
>>> On Tue, Sep 12, 2017 at 1:49 PM, Алексей  wrote:
>>> > Think of it from a different way: if there would be no ',' how would
>>> you
>>> > react on the idea of adding it? Peaty sour every one would decide that
>>> would
>>> > be a complete nonsense.
>>>
>>> This sort of hypothetical isn't useful; you're not proposing switching
>>> over to *solely* comma-less, you're proposing a *mixture* of comma and
>>> comma-less being allowed.  That has very different ergonomics than
>>> either all-comma or all-comma-less.
>>>
>>> The hypothetical comma-less language would also have made many
>>> different syntax decisions over the years to accommodate that, which
>>> current JS has *not* made.  This causes the sorts of problems that
>>> Claude/etc have pointed out.
>>>
>>> ~TJ
>>> ___
>>> es-discuss mailing list
>>> es-discuss@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>> ___
>> es-discuss mailing list
>> es-discuss@mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>> ___
> es-discuss mailing list
> es-discuss@mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss