Re: Exponentiation operator precedence

[Marius Gundersen]

One advantage of #4 is that it will make it possible to introduce either #2
or #3 in the future, if we change our minds. This way we can use real world
use cases to decide if we should go for #2 or #3.

Marius Gundersen

On Fri, Sep 25, 2015 at 1:23 AM, Waldemar Horwat 
wrote:

> My preference is for 2, but I don't have objections to 4.  Either works.
>
> Waldemar
>
> ___
> 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: Object.clone - not quite a proposal

[Andrea Giammarchi]

Also, one reason I haven't used that, if you clone descriptors you do a
shallow copy, not a deep one ;-)

On Fri, Sep 25, 2015 at 2:31 AM, Andrea Giammarchi <
andrea.giammar...@gmail.com> wrote:

> Claude, you know that's actually *my* proposal, right? :P
> https://gist.github.com/WebReflection/9353781
>
> But yeah, that's the spirit!
>
> On Thu, Sep 24, 2015 at 8:21 PM, Claude Pache 
> wrote:
>
>>
>> Le 24 sept. 2015 à 19:58, Andrea Giammarchi 
>> a écrit :
>>
>> Last, but not least, one does not simply assign properties in JavaScript.
>> If you want to clone you don't want to miss possible get/set accessors in
>> the process, you don't want to miss getOwnPropertyNames and
>> getOwnpropertySymbols neither, so the last loop doesn't work as proposal.
>>
>> ```js
>> // simplified version for regular objects only
>> // basically just the correct substitute of your last temp logic
>> Object.clone = function (src) {
>>   return Object.setPrototypeOf(
>> Reflect.ownKeys(src).reduce((o, k) => {
>>   var d = Object.getOwnPropertyDescriptor(src, k);
>>   if (
>> o.hasOwnProperty.call(d, 'value') &&
>> /function|object/.test(typeof d.value)
>>   ) d.value = Object.clone(d.value);
>>   return Object.defineProperty(o, k, d);
>> }, {}),
>> Object.getPrototypeOf(src)
>>   );
>> };
>> ```
>>
>>
>> ```js
>> Object.clone = function (src) {
>> return Object.create(Object.getPrototypeOf(src),
>> Object.getOwnPropertyDescriptors(src))
>> }
>> ```
>>
>> where  the definition of `Object.getOwnPropertyDescriptors()` is left as
>> an exercise to the reader.
>>
>>
>> —Claude
>>
>>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.clone - not quite a proposal

[Andrea Giammarchi]

Claude, you know that's actually *my* proposal, right? :P
https://gist.github.com/WebReflection/9353781

But yeah, that's the spirit!

On Thu, Sep 24, 2015 at 8:21 PM, Claude Pache 
wrote:

>
> Le 24 sept. 2015 à 19:58, Andrea Giammarchi 
> a écrit :
>
> Last, but not least, one does not simply assign properties in JavaScript.
> If you want to clone you don't want to miss possible get/set accessors in
> the process, you don't want to miss getOwnPropertyNames and
> getOwnpropertySymbols neither, so the last loop doesn't work as proposal.
>
> ```js
> // simplified version for regular objects only
> // basically just the correct substitute of your last temp logic
> Object.clone = function (src) {
>   return Object.setPrototypeOf(
> Reflect.ownKeys(src).reduce((o, k) => {
>   var d = Object.getOwnPropertyDescriptor(src, k);
>   if (
> o.hasOwnProperty.call(d, 'value') &&
> /function|object/.test(typeof d.value)
>   ) d.value = Object.clone(d.value);
>   return Object.defineProperty(o, k, d);
> }, {}),
> Object.getPrototypeOf(src)
>   );
> };
> ```
>
>
> ```js
> Object.clone = function (src) {
> return Object.create(Object.getPrototypeOf(src),
> Object.getOwnPropertyDescriptors(src))
> }
> ```
>
> where  the definition of `Object.getOwnPropertyDescriptors()` is left as
> an exercise to the reader.
>
>
> —Claude
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

[Waldemar Horwat]

My preference is for 2, but I don't have objections to 4.  Either works.

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

Re: Exponentiation operator precedence

[Brendan Eich]

The worry over the meaning of (- x ** y) arises not just due to conventions
or inference from typography, but from intuitions based on limited
knowledge. As Dave Herman pointed out yesterday, many programmers (most) do
not have the full precedence and associativity set memorized. When in
doubt, they will rely on precedent in the language, visual cues including
weight of operator (two chars vs. one), unary vs. binary. When in more
doubt, they'll over-parenthesize.

The problem case is exactly the user cohort who'll not have enough doubt to
over-parenthesize, who will rely on precedent and typographic weight clues,
sound or not.

Mark Miller pointed out how many reviewers missed the problem with the
original proposal as predicting likely confusion at scale. If we can avoid
any confusion with an error, and force the people who should
over-parenthesize to do so, while taxing the Math fans to do it when they
must as well, this seems more prudent than just sticking with the
Math-trumps-JS precedent and letting wrong results pass silently at runtime.

(I see no reason to disallow right-associative chaining. We haven't run
head-on into confusion by drafting it the wrong way and getting it to stage
3 :-P.)

/be

On Thu, Sep 24, 2015 at 2:05 PM, Claude Pache 
wrote:

>
> Le 24 sept. 2015 à 22:20, Brendan Eich  a écrit :
>
> Sez you! :-P
>
> Seriously, the problem you are dismissing implicitly (bad form :-/) is the
> one we discussed yesterday, which I've stated explicitly twice now: the
> typography and plain sense of JS-in-itself suggests unary minus binds
> tighter than any binary connective (including **).
>
>
> It’s more a question of convention than of typography, as in: `x + y * z`
> or: `x || y && z`.
>
> There are two conflicting conventions here, not two conflicting
> typographies. For the set of operators defined in C, the convention of
> making every unary operator having a higher precedence, does not conflict
> with the conventions used in math. (It is not clear for me why that
> convention is important, just that it is a handy uniform rule that works
> well for some limited set of operators.)
>
> Note that if you want to disallow `-x**y`, you might want to disallow
> `x**y**z` (which is imho more confusing), as there is no other
> right-associative binary operator (except assignment).
>
> —Claude
>
>
> Saying "Math!" doesn't overcome this, any more than shouting "typography!"
> or "JS-in-itself!"
>
> You don't get to pick a winner just because you root for one team. If you
> think the operator is worth adding and you concede that the other team's
> position is tenable because enough people are confused on the committee to
> predict a wider problem, then you have to consider whether the hardship of
> mandatory parens in the rare case of negated exponentiation expression is
> onerous.
>
> It's not a source of runtime bugs, where test coverage is never good
> enough. It's a SyntaxError, so (a) Math uber alles people who (b) run into
> the rare hard case will learn to parenthesize.
>
> I suspect that many Math-should-prevail types (I am among them in the
> abstract, prior to engaging with the human factors at play in JS) will want
> to parenthesize anyway, given the typographic appearance of precedence
> inversion. I will certainly do it if there's any unary prefixing an
> exponentiation expression in my code.
>
> I did find a formula search engine. See
> http://www.searchonmath.com/result?equation=-+x%5E%7By%7D&page=1&tm=1 for
> a taste of the hard cases (and false positives, which do not count).
>
> Methinks you protest too much. Where is the common case made hard by
> proposal (4)?
>
> /be
>
>
> On Thu, Sep 24, 2015 at 12:29 PM, Domenic Denicola  wrote:
>
>> I object to #4. Disallowing perfectly reasonable math expressions
>> (Claude's is a good example) makes this operator too surprising to include
>> in the language.
>>
>>
>>
>> *From:* Brendan Eich 
>> *Sent:* Sep 24, 2015 13:18
>> *To:* Mark S. Miller; Claude Pache
>> *Cc:* es-discuss
>> *Subject:* Re: Exponentiation operator precedence
>>
>> Right. It's confusing because (as opposed to Math), ** is not a
>> superscripting operator whose typography suggests higher precedence than -,
>> and this matters for the sign of the result when exponentiating.
>>
>> Claude, the Math folks won't often need to negate the result, but when
>> they do, they'll have to parenthesize. That's the price of the typographic
>> shift and the precedence inversion that it suggests to many people.
>>
>> /be
>>
>> On Thu, Sep 24, 2015 at 11:16 AM, Mark S. Miller 
>> wrote:
>>
>>>
>>>
>>> On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache 
>>> wrote:
>>>

 Le 24 sept. 2015 à 16:11, Brendan Eich  a écrit :

 And indeed apart from dot (a special form whose right operand must be a
 lexical identifier-name) and square brackets (which isn't an infix operator
 per se), unary operators bind tighter than binary in JS as in C and other
 C-derived languages.

>

Re: Exponentiation operator precedence

[Claude Pache]

> Le 24 sept. 2015 à 22:20, Brendan Eich  a écrit :
> 
> Sez you! :-P
> 
> Seriously, the problem you are dismissing implicitly (bad form :-/) is the 
> one we discussed yesterday, which I've stated explicitly twice now: the 
> typography and plain sense of JS-in-itself suggests unary minus binds tighter 
> than any binary connective (including **).

It’s more a question of convention than of typography, as in: `x + y * z` or: 
`x || y && z`.

There are two conflicting conventions here, not two conflicting typographies. 
For the set of operators defined in C, the convention of making every unary 
operator having a higher precedence, does not conflict with the conventions 
used in math. (It is not clear for me why that convention is important, just 
that it is a handy uniform rule that works well for some limited set of 
operators.)

Note that if you want to disallow `-x**y`, you might want to disallow `x**y**z` 
(which is imho more confusing), as there is no other right-associative binary 
operator (except assignment).

—Claude

> 
> Saying "Math!" doesn't overcome this, any more than shouting "typography!" or 
> "JS-in-itself!"
> 
> You don't get to pick a winner just because you root for one team. If you 
> think the operator is worth adding and you concede that the other team's 
> position is tenable because enough people are confused on the committee to 
> predict a wider problem, then you have to consider whether the hardship of 
> mandatory parens in the rare case of negated exponentiation expression is 
> onerous.
> 
> It's not a source of runtime bugs, where test coverage is never good enough. 
> It's a SyntaxError, so (a) Math uber alles people who (b) run into the rare 
> hard case will learn to parenthesize.
> 
> I suspect that many Math-should-prevail types (I am among them in the 
> abstract, prior to engaging with the human factors at play in JS) will want 
> to parenthesize anyway, given the typographic appearance of precedence 
> inversion. I will certainly do it if there's any unary prefixing an 
> exponentiation expression in my code.
> 
> I did find a formula search engine. See 
> http://www.searchonmath.com/result?equation=-+x%5E%7By%7D&page=1&tm=1 
>  for a 
> taste of the hard cases (and false positives, which do not count).
> 
> Methinks you protest too much. Where is the common case made hard by proposal 
> (4)?
> 
> /be
> 
> 
> On Thu, Sep 24, 2015 at 12:29 PM, Domenic Denicola  > wrote:
> I object to #4. Disallowing perfectly reasonable math expressions (Claude's 
> is a good example) makes this operator too surprising to include in the 
> language.
> 
>  
> 
> From: Brendan Eich mailto:brendan.e...@gmail.com>>
> Sent: Sep 24, 2015 13:18
> To: Mark S. Miller; Claude Pache
> Cc: es-discuss
> Subject: Re: Exponentiation operator precedence
> 
> Right. It's confusing because (as opposed to Math), ** is not a 
> superscripting operator whose typography suggests higher precedence than -, 
> and this matters for the sign of the result when exponentiating.
> 
> Claude, the Math folks won't often need to negate the result, but when they 
> do, they'll have to parenthesize. That's the price of the typographic shift 
> and the precedence inversion that it suggests to many people.
> 
> /be
> 
> On Thu, Sep 24, 2015 at 11:16 AM, Mark S. Miller  > wrote:
> 
> 
> On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache  > wrote:
> 
>> Le 24 sept. 2015 à 16:11, Brendan Eich > > a écrit :
>> 
>> And indeed apart from dot (a special form whose right operand must be a 
>> lexical identifier-name) and square brackets (which isn't an infix operator 
>> per se), unary operators bind tighter than binary in JS as in C and other 
>> C-derived languages.
> 
> I just wonder why it is important that unary binds tighter? For instance, 
> before I carefully studied the issue of this thread, I have never expected 
> that unary minus binds tighter than binary
> 
> 
> Before Jason pointed out the discrepancy:
>   * all of us on the committee who were engaged with the proposal
>   * including myself,
>   * all those who reviewed the proposal, 
>   * and all those who implemented the proposal 
> had the opposite naive expectation. That's the point. In the absence of 
> learning about this case specifically, many people will be unpleasantly 
> surprised by #2, and many by #3. Therefore #4 wins. (Actually, it just won 
> ;).)
> 
> 
> 
>  
> multiplication operator in expressions like `-2*x` (although it does not 
> matter in that case).
> 
>> 
>> without having to parenthesize unduly, but one cannot write
>> 
>> let z = -x ** y;
>> 
>> The user is forced by an early error to write either (-x)**y or -(x**y).
> 
> In traditional math notation, when you mean `(-x)**n`, you write (-x)ⁿ with 
> mandatory parentheses, so I don’t expect that many people 

Re: Exponentiation operator precedence

[Brendan Eich]

Sez you! :-P

Seriously, the problem you are dismissing implicitly (bad form :-/) is the
one we discussed yesterday, which I've stated explicitly twice now: the
typography and plain sense of JS-in-itself suggests unary minus binds
tighter than any binary connective (including **).

Saying "Math!" doesn't overcome this, any more than shouting "typography!"
or "JS-in-itself!"

You don't get to pick a winner just because you root for one team. If you
think the operator is worth adding and you concede that the other team's
position is tenable because enough people are confused on the committee to
predict a wider problem, then you have to consider whether the hardship of
mandatory parens in the rare case of negated exponentiation expression is
onerous.

It's not a source of runtime bugs, where test coverage is never good
enough. It's a SyntaxError, so (a) Math uber alles people who (b) run into
the rare hard case will learn to parenthesize.

I suspect that many Math-should-prevail types (I am among them in the
abstract, prior to engaging with the human factors at play in JS) will want
to parenthesize anyway, given the typographic appearance of precedence
inversion. I will certainly do it if there's any unary prefixing an
exponentiation expression in my code.

I did find a formula search engine. See
http://www.searchonmath.com/result?equation=-+x%5E%7By%7D&page=1&tm=1 for a
taste of the hard cases (and false positives, which do not count).

Methinks you protest too much. Where is the common case made hard by
proposal (4)?

/be


On Thu, Sep 24, 2015 at 12:29 PM, Domenic Denicola  wrote:

> I object to #4. Disallowing perfectly reasonable math expressions
> (Claude's is a good example) makes this operator too surprising to include
> in the language.
>
>
>
> *From:* Brendan Eich 
> *Sent:* Sep 24, 2015 13:18
> *To:* Mark S. Miller; Claude Pache
> *Cc:* es-discuss
> *Subject:* Re: Exponentiation operator precedence
>
> Right. It's confusing because (as opposed to Math), ** is not a
> superscripting operator whose typography suggests higher precedence than -,
> and this matters for the sign of the result when exponentiating.
>
> Claude, the Math folks won't often need to negate the result, but when
> they do, they'll have to parenthesize. That's the price of the typographic
> shift and the precedence inversion that it suggests to many people.
>
> /be
>
> On Thu, Sep 24, 2015 at 11:16 AM, Mark S. Miller 
> wrote:
>
>>
>>
>> On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache 
>> wrote:
>>
>>>
>>> Le 24 sept. 2015 à 16:11, Brendan Eich  a écrit :
>>>
>>> And indeed apart from dot (a special form whose right operand must be a
>>> lexical identifier-name) and square brackets (which isn't an infix operator
>>> per se), unary operators bind tighter than binary in JS as in C and other
>>> C-derived languages.
>>>
>>>
>>> I just wonder why it is important that unary binds tighter? For
>>> instance, before I carefully studied the issue of this thread, I have never
>>> expected that unary minus binds tighter than binary
>>>
>>
>>
>> Before Jason pointed out the discrepancy:
>>   * all of us on the committee who were engaged with the proposal
>>   * including myself,
>>   * all those who reviewed the proposal,
>>   * and all those who implemented the proposal
>> had the opposite naive expectation. That's the point. In the absence of
>> learning about this case specifically, many people will be unpleasantly
>> surprised by #2, and many by #3. Therefore #4 wins. (Actually, it just won
>> ;).)
>>
>>
>>
>>
>>
>>> multiplication operator in expressions like `-2*x` (although it does not
>>> matter in that case).
>>>
>>>
>>> without having to parenthesize unduly, but one cannot write
>>>
>>> let z = -x ** y;
>>>
>>> The user is forced by an early error to write either (-x)**y or -(x**y).
>>>
>>>
>>> In traditional math notation, when you mean `(-x)**n`, you write (-x)ⁿ
>>> with mandatory parentheses, so I don’t expect that many people will be
>>> tempted to miswrite it `-x ** n`.
>>>
>>> Making the parentheses mandatory here will be somewhat annoying in
>>> perfectly reasonable expressions, where you usually don’t use parentheses
>>> in real math notation., like:
>>> ```
>>> let s2 =  - x**2 - y**2 - z**2 +  t**2
>>> ```
>>>
>>> —Claude
>>>
>>>
>>>
>>
>>
>> --
>> Cheers,
>> --MarkM
>>
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

[Domenic Denicola]

I object to #4. Disallowing perfectly reasonable math expressions (Claude's is 
a good example) makes this operator too surprising to include in the language.



From: Brendan Eich 
Sent: Sep 24, 2015 13:18
To: Mark S. Miller; Claude Pache
Cc: es-discuss
Subject: Re: Exponentiation operator precedence

Right. It's confusing because (as opposed to Math), ** is not a superscripting 
operator whose typography suggests higher precedence than -, and this matters 
for the sign of the result when exponentiating.

Claude, the Math folks won't often need to negate the result, but when they do, 
they'll have to parenthesize. That's the price of the typographic shift and the 
precedence inversion that it suggests to many people.

/be

On Thu, Sep 24, 2015 at 11:16 AM, Mark S. Miller 
mailto:erig...@google.com>> wrote:


On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache 
mailto:claude.pa...@gmail.com>> wrote:

Le 24 sept. 2015 à 16:11, Brendan Eich 
mailto:bren...@mozilla.org>> a écrit :

And indeed apart from dot (a special form whose right operand must be a lexical 
identifier-name) and square brackets (which isn't an infix operator per se), 
unary operators bind tighter than binary in JS as in C and other C-derived 
languages.

I just wonder why it is important that unary binds tighter? For instance, 
before I carefully studied the issue of this thread, I have never expected that 
unary minus binds tighter than binary


Before Jason pointed out the discrepancy:
  * all of us on the committee who were engaged with the proposal
  * including myself,
  * all those who reviewed the proposal,
  * and all those who implemented the proposal
had the opposite naive expectation. That's the point. In the absence of 
learning about this case specifically, many people will be unpleasantly 
surprised by #2, and many by #3. Therefore #4 wins. (Actually, it just won ;).)




multiplication operator in expressions like `-2*x` (although it does not matter 
in that case).


without having to parenthesize unduly, but one cannot write

let z = -x ** y;

The user is forced by an early error to write either (-x)**y or -(x**y).

In traditional math notation, when you mean `(-x)**n`, you write (-x)ⁿ with 
mandatory parentheses, so I don’t expect that many people will be tempted to 
miswrite it `-x ** n`.

Making the parentheses mandatory here will be somewhat annoying in perfectly 
reasonable expressions, where you usually don’t use parentheses in real math 
notation., like:
```
let s2 =  - x**2 - y**2 - z**2 +  t**2
```

—Claude





--
Cheers,
--MarkM

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

Re: Object.clone - not quite a proposal

[Jordan Harband]

Cloning is not a trivial matter. You may be interested in these previous
discussions before discussing further:

 - https://esdiscuss.org/topic/the-structured-clone-wars
 - https://esdiscuss.org/topic/structured-clones
 -
https://esdiscuss.org/topic/structured-cloning-transfering-of-promises-and-streams
 - https://esdiscuss.org/topic/how-would-we-copy-anything
 - https://esdiscuss.org/topic/deep-cloning-objects-defined-by-json

- Jordan

On Thu, Sep 24, 2015 at 11:42 AM, Jeremy Darling 
wrote:

> The code was only meant to be a better explanation of the goal, but yes it
> would have to take into account getters, setters, etc...
>
> Actually it was a copy/paste edit of some code we use for cloning
> (deserialized) JSON objects for API reproduction.  There is an omit stage
> that was removed and since it was originally designed around JSON
> structures there is no built in support for custom properties, getters,
> setters.
>
> DOM nodes I'm not sure how you would account for.  In all actuality I
> would think they would throw an error, but maybe they shouldn't.  Magically
> appearing textboxes could be a bad thing :D
>
> On Thu, Sep 24, 2015 at 1:21 PM, Claude Pache 
> wrote:
>
>>
>> Le 24 sept. 2015 à 19:58, Andrea Giammarchi 
>> a écrit :
>>
>> Last, but not least, one does not simply assign properties in JavaScript.
>> If you want to clone you don't want to miss possible get/set accessors in
>> the process, you don't want to miss getOwnPropertyNames and
>> getOwnpropertySymbols neither, so the last loop doesn't work as proposal.
>>
>> ```js
>> // simplified version for regular objects only
>> // basically just the correct substitute of your last temp logic
>> Object.clone = function (src) {
>>   return Object.setPrototypeOf(
>> Reflect.ownKeys(src).reduce((o, k) => {
>>   var d = Object.getOwnPropertyDescriptor(src, k);
>>   if (
>> o.hasOwnProperty.call(d, 'value') &&
>> /function|object/.test(typeof d.value)
>>   ) d.value = Object.clone(d.value);
>>   return Object.defineProperty(o, k, d);
>> }, {}),
>> Object.getPrototypeOf(src)
>>   );
>> };
>> ```
>>
>>
>> ```js
>> Object.clone = function (src) {
>> return Object.create(Object.getPrototypeOf(src),
>> Object.getOwnPropertyDescriptors(src))
>> }
>> ```
>>
>> where  the definition of `Object.getOwnPropertyDescriptors()` is left as
>> an exercise to the reader.
>>
>>
>> —Claude
>>
>>
>
> ___
> 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: Object.clone - not quite a proposal

[Jeremy Darling]

The code was only meant to be a better explanation of the goal, but yes it
would have to take into account getters, setters, etc...

Actually it was a copy/paste edit of some code we use for cloning
(deserialized) JSON objects for API reproduction.  There is an omit stage
that was removed and since it was originally designed around JSON
structures there is no built in support for custom properties, getters,
setters.

DOM nodes I'm not sure how you would account for.  In all actuality I would
think they would throw an error, but maybe they shouldn't.  Magically
appearing textboxes could be a bad thing :D

On Thu, Sep 24, 2015 at 1:21 PM, Claude Pache 
wrote:

>
> Le 24 sept. 2015 à 19:58, Andrea Giammarchi 
> a écrit :
>
> Last, but not least, one does not simply assign properties in JavaScript.
> If you want to clone you don't want to miss possible get/set accessors in
> the process, you don't want to miss getOwnPropertyNames and
> getOwnpropertySymbols neither, so the last loop doesn't work as proposal.
>
> ```js
> // simplified version for regular objects only
> // basically just the correct substitute of your last temp logic
> Object.clone = function (src) {
>   return Object.setPrototypeOf(
> Reflect.ownKeys(src).reduce((o, k) => {
>   var d = Object.getOwnPropertyDescriptor(src, k);
>   if (
> o.hasOwnProperty.call(d, 'value') &&
> /function|object/.test(typeof d.value)
>   ) d.value = Object.clone(d.value);
>   return Object.defineProperty(o, k, d);
> }, {}),
> Object.getPrototypeOf(src)
>   );
> };
> ```
>
>
> ```js
> Object.clone = function (src) {
> return Object.create(Object.getPrototypeOf(src),
> Object.getOwnPropertyDescriptors(src))
> }
> ```
>
> where  the definition of `Object.getOwnPropertyDescriptors()` is left as
> an exercise to the reader.
>
>
> —Claude
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Object.clone - not quite a proposal

[Claude Pache]

> Le 24 sept. 2015 à 19:58, Andrea Giammarchi  a 
> écrit :
> 
> Last, but not least, one does not simply assign properties in JavaScript. If 
> you want to clone you don't want to miss possible get/set accessors in the 
> process, you don't want to miss getOwnPropertyNames and getOwnpropertySymbols 
> neither, so the last loop doesn't work as proposal.
> 
> ```js
> // simplified version for regular objects only
> // basically just the correct substitute of your last temp logic
> Object.clone = function (src) {
>   return Object.setPrototypeOf(
> Reflect.ownKeys(src).reduce((o, k) => {
>   var d = Object.getOwnPropertyDescriptor(src, k);
>   if (
> o.hasOwnProperty.call(d, 'value') &&
> /function|object/.test(typeof d.value)
>   ) d.value = Object.clone(d.value);
>   return Object.defineProperty(o, k, d);
> }, {}),
> Object.getPrototypeOf(src)
>   );
> };
> ```

```js
Object.clone = function (src) {
return Object.create(Object.getPrototypeOf(src), 
Object.getOwnPropertyDescriptors(src))
}
```

where  the definition of `Object.getOwnPropertyDescriptors()` is left as an 
exercise to the reader.


—Claude

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

Re: Exponentiation operator precedence

[Brendan Eich]

Right. It's confusing because (as opposed to Math), ** is not a
superscripting operator whose typography suggests higher precedence than -,
and this matters for the sign of the result when exponentiating.

Claude, the Math folks won't often need to negate the result, but when they
do, they'll have to parenthesize. That's the price of the typographic shift
and the precedence inversion that it suggests to many people.

/be

On Thu, Sep 24, 2015 at 11:16 AM, Mark S. Miller  wrote:

>
>
> On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache 
> wrote:
>
>>
>> Le 24 sept. 2015 à 16:11, Brendan Eich  a écrit :
>>
>> And indeed apart from dot (a special form whose right operand must be a
>> lexical identifier-name) and square brackets (which isn't an infix operator
>> per se), unary operators bind tighter than binary in JS as in C and other
>> C-derived languages.
>>
>>
>> I just wonder why it is important that unary binds tighter? For instance,
>> before I carefully studied the issue of this thread, I have never expected
>> that unary minus binds tighter than binary
>>
>
>
> Before Jason pointed out the discrepancy:
>   * all of us on the committee who were engaged with the proposal
>   * including myself,
>   * all those who reviewed the proposal,
>   * and all those who implemented the proposal
> had the opposite naive expectation. That's the point. In the absence of
> learning about this case specifically, many people will be unpleasantly
> surprised by #2, and many by #3. Therefore #4 wins. (Actually, it just won
> ;).)
>
>
>
>
>
>> multiplication operator in expressions like `-2*x` (although it does not
>> matter in that case).
>>
>>
>> without having to parenthesize unduly, but one cannot write
>>
>> let z = -x ** y;
>>
>> The user is forced by an early error to write either (-x)**y or -(x**y).
>>
>>
>> In traditional math notation, when you mean `(-x)**n`, you write (-x)ⁿ
>> with mandatory parentheses, so I don’t expect that many people will be
>> tempted to miswrite it `-x ** n`.
>>
>> Making the parentheses mandatory here will be somewhat annoying in
>> perfectly reasonable expressions, where you usually don’t use parentheses
>> in real math notation., like:
>> ```
>> let s2 =  - x**2 - y**2 - z**2 +  t**2
>> ```
>>
>> —Claude
>>
>>
>>
>
>
> --
> Cheers,
> --MarkM
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

[Mark S. Miller]

On Thu, Sep 24, 2015 at 11:08 AM, Claude Pache 
wrote:

>
> Le 24 sept. 2015 à 16:11, Brendan Eich  a écrit :
>
> And indeed apart from dot (a special form whose right operand must be a
> lexical identifier-name) and square brackets (which isn't an infix operator
> per se), unary operators bind tighter than binary in JS as in C and other
> C-derived languages.
>
>
> I just wonder why it is important that unary binds tighter? For instance,
> before I carefully studied the issue of this thread, I have never expected
> that unary minus binds tighter than binary
>


Before Jason pointed out the discrepancy:
  * all of us on the committee who were engaged with the proposal
  * including myself,
  * all those who reviewed the proposal,
  * and all those who implemented the proposal
had the opposite naive expectation. That's the point. In the absence of
learning about this case specifically, many people will be unpleasantly
surprised by #2, and many by #3. Therefore #4 wins. (Actually, it just won
;).)





> multiplication operator in expressions like `-2*x` (although it does not
> matter in that case).
>
>
> without having to parenthesize unduly, but one cannot write
>
> let z = -x ** y;
>
> The user is forced by an early error to write either (-x)**y or -(x**y).
>
>
> In traditional math notation, when you mean `(-x)**n`, you write (-x)ⁿ
> with mandatory parentheses, so I don’t expect that many people will be
> tempted to miswrite it `-x ** n`.
>
> Making the parentheses mandatory here will be somewhat annoying in
> perfectly reasonable expressions, where you usually don’t use parentheses
> in real math notation., like:
> ```
> let s2 =  - x**2 - y**2 - z**2 +  t**2
> ```
>
> —Claude
>
>
>


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

Re: Exponentiation operator precedence

[Claude Pache]

> Le 24 sept. 2015 à 16:11, Brendan Eich  a écrit :
> 
> And indeed apart from dot (a special form whose right operand must be a 
> lexical identifier-name) and square brackets (which isn't an infix operator 
> per se), unary operators bind tighter than binary in JS as in C and other 
> C-derived languages.

I just wonder why it is important that unary binds tighter? For instance, 
before I carefully studied the issue of this thread, I have never expected that 
unary minus binds tighter than binary multiplication operator in expressions 
like `-2*x` (although it does not matter in that case).

> 
> without having to parenthesize unduly, but one cannot write
> 
> let z = -x ** y;
> 
> The user is forced by an early error to write either (-x)**y or -(x**y).

In traditional math notation, when you mean `(-x)**n`, you write (-x)ⁿ with 
mandatory parentheses, so I don’t expect that many people will be tempted to 
miswrite it `-x ** n`.

Making the parentheses mandatory here will be somewhat annoying in perfectly 
reasonable expressions, where you usually don’t use parentheses in real math 
notation., like:
```
let s2 =  - x**2 - y**2 - z**2 +  t**2
```

—Claude


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

Re: Object.clone - not quite a proposal

[Andrea Giammarchi]

return src.map((item)=>clone(item));
probably
return src.map(Object.clone);
would do, if it accepts only one argument.

It seems that HTML nodes are missing (through document.createXXX) and it
relies on `instanceof` which works for me but it doesn't as proposal 'cause
incompatible cross realms.

Last, but not least, one does not simply assign properties in JavaScript.
If you want to clone you don't want to miss possible get/set accessors in
the process, you don't want to miss getOwnPropertyNames and
getOwnpropertySymbols neither, so the last loop doesn't work as proposal.

```js
// simplified version for regular objects only
// basically just the correct substitute of your last temp logic
Object.clone = function (src) {
  return Object.setPrototypeOf(
Reflect.ownKeys(src).reduce((o, k) => {
  var d = Object.getOwnPropertyDescriptor(src, k);
  if (
o.hasOwnProperty.call(d, 'value') &&
/function|object/.test(typeof d.value)
  ) d.value = Object.clone(d.value);
  return Object.defineProperty(o, k, d);
}, {}),
Object.getPrototypeOf(src)
  );
};
```

That should be kinda better, IMO, and if you need to test with Reflect you
can:
```js
var Reflect = Reflect || {
  ownKeys: (o) => Object.getOwnPropertyNames(o).concat(
Object.getOwnPropertySymbols(o)
  )
};
```


Best Regards





On Thu, Sep 24, 2015 at 6:15 PM, Jeremy Darling 
wrote:

> I'm horrid with proposals, but this seems like a missing hole and I
> couldn't find a previous mention of it.
>
> Looking at the Object support methods it seems that the only thing that
> doesn't exist is a (simple) way to clone an object and all of its members.
>
> Ideally would allow creation of immutable and/or deep/shallow clones of
> existing Object/Array/RegExp/Date/...
>
> Basic shim (most likely not perfect):
>
> Object.clone = function(src){
>   if(!src || typeof(src) !== 'object'){
> return src;
>   }
>   if(src instanceof Date){
> return new Date(src);
>   }
>   if(src instanceof Array){
> return src.map((item)=>clone(item));
>   }
>   if(src instanceof RegExp){
> return new RegExp(src);
>   }
>   var temp = (src.prototype)?Object.create(src.prototype):new
> src.constructor();
>   Object.keys(src).forEach((key)=>{temp[key] = Object.clone(src[key]);});
>   return temp;
> };
>
> Thoughts?
>  - Jeremy
>
> ___
> 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: Exponentiation operator precedence

[Rick Waldron]

Thanks again to Brendan for taking time to write this up. And to Mark,
thanks for reviewing this and expeditiously providing valuable
feedback—it's greatly appreciated.

Rick
On Thu, Sep 24, 2015 at 8:27 AM Mark S. Miller  wrote:

> I won't try to guess where the rendering problem is, but see the attached
> screenshots. This is how I'm seeing your page on my Chrome and Firefox.
>
> On Thu, Sep 24, 2015 at 8:19 AM, Brendan Eich  wrote:
>
>> Even nicer:
>>
>> http://jsbin.com/baquqokujo
>>
>> I hate email.
>>
>> /be
>>
>>
>> Brendan Eich wrote:
>>
>>> Here's a nicely formatted jsbin version of my message:
>>>
>>> http://jsbin.com/bihilaveda
>>>
>>> Sorry about the mess, mail user agents (at least Postbox) and archive
>>> software do not like explicit indentation.
>>>
>>> /be
>>>
>>
>>
>
>
> --
> Cheers,
> --MarkM
> ___
> 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

Object.clone - not quite a proposal

[Jeremy Darling]

I'm horrid with proposals, but this seems like a missing hole and I
couldn't find a previous mention of it.

Looking at the Object support methods it seems that the only thing that
doesn't exist is a (simple) way to clone an object and all of its members.

Ideally would allow creation of immutable and/or deep/shallow clones of
existing Object/Array/RegExp/Date/...

Basic shim (most likely not perfect):

Object.clone = function(src){
  if(!src || typeof(src) !== 'object'){
return src;
  }
  if(src instanceof Date){
return new Date(src);
  }
  if(src instanceof Array){
return src.map((item)=>clone(item));
  }
  if(src instanceof RegExp){
return new RegExp(src);
  }
  var temp = (src.prototype)?Object.create(src.prototype):new
src.constructor();
  Object.keys(src).forEach((key)=>{temp[key] = Object.clone(src[key]);});
  return temp;
};

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

Re: Fix Left-Associative Compound Conditional Statements!!

[Joseph Groseclose]

At some length I see, heh. Alright, I guess that just about sums it up.

On Thu, Sep 24, 2015 at 11:01 AM, Claude Pache 
wrote:

> For an old discussion on the same subject, see:
>
>
> https://esdiscuss.org/topic/chained-comparisons-from-python-and-coffeescript
>
> —Claude
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

[Mark S. Miller]

I won't try to guess where the rendering problem is, but see the attached
screenshots. This is how I'm seeing your page on my Chrome and Firefox.

On Thu, Sep 24, 2015 at 8:19 AM, Brendan Eich  wrote:

> Even nicer:
>
> http://jsbin.com/baquqokujo
>
> I hate email.
>
> /be
>
>
> Brendan Eich wrote:
>
>> Here's a nicely formatted jsbin version of my message:
>>
>> http://jsbin.com/bihilaveda
>>
>> Sorry about the mess, mail user agents (at least Postbox) and archive
>> software do not like explicit indentation.
>>
>> /be
>>
>
>


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

Re: Exponentiation operator precedence

[Andreas Rossberg]

On 24 September 2015 at 17:19, Brendan Eich  wrote:

> Even nicer:
>
> http://jsbin.com/baquqokujo
>
> I hate email.


You are holding it wrong.

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

Re: Exponentiation operator precedence

[Brendan Eich]

Even nicer:

http://jsbin.com/baquqokujo

I hate email.

/be

Brendan Eich wrote:

Here's a nicely formatted jsbin version of my message:

http://jsbin.com/bihilaveda

Sorry about the mess, mail user agents (at least Postbox) and archive 
software do not like explicit indentation.


/be 


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

Re: Exponentiation operator precedence

[Mark S. Miller]

I like #4. Normally in a situation like this I would still argue for #1. #4
is a complicated special case that breaks the normal pattern of operator
precedence elsewhere in the language. The need for ** is not great enough
to justify introducing a new special case for users to learn.

However, in this case, #4 is only technically complicated -- for those
writing or reading spec docs like us. For normal users, the only complexity
is a rarely encountered surprising static error. With a decent (and easy to
generate) error message, these users will immediately know what they need
to do to repair their program.

Significant programs are read much more than they are written. Both #2 and
#3 will lead many readers to misread programs. For programs that are not
rejected, #4 is no more confusing than #1. Altogether, for readers, #4 is
better than #1 because ** is more readable than Pow.

+1 on #4.



On Thu, Sep 24, 2015 at 7:55 AM, Brendan Eich  wrote:

> Here's a nicely formatted jsbin version of my message:
>
> http://jsbin.com/bihilaveda
>
> Sorry about the mess, mail user agents (at least Postbox) and archive
> software do not like explicit indentation.
>
> /be
>
>
>
>


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

Re: Fix Left-Associative Compound Conditional Statements!!

[Claude Pache]

For an old discussion on the same subject, see:

https://esdiscuss.org/topic/chained-comparisons-from-python-and-coffeescript 


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

Re: Fix Left-Associative Compound Conditional Statements!!

[Till Schneidereit]

On Thu, Sep 24, 2015 at 4:50 PM, Joseph Groseclose 
wrote:

> Isn't this logic theoretically broken? If any existing code is using it,
> the code that is using it is probably performing an invalid or inaccurate
> operation and therefore this would only break that code so much as it was
> already not functioning as expected?
>

There are many examples of code that doesn't really do what the author
thought it does, but just so happens to do what's required to produce a
correct result in combination with other, potentially equally "incorrect"
code. "Fixing" the logic here would mean breaking the overall program.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

[Brendan Eich]

Here's a nicely formatted jsbin version of my message:

http://jsbin.com/bihilaveda

Sorry about the mess, mail user agents (at least Postbox) and archive 
software do not like explicit indentation.


/be



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

Re: Fix Left-Associative Compound Conditional Statements!!

[Joseph Groseclose]

Isn't this logic theoretically broken? If any existing code is using it,
the code that is using it is probably performing an invalid or inaccurate
operation and therefore this would only break that code so much as it was
already not functioning as expected?

On Thu, Sep 24, 2015 at 10:40 AM, Kevin Smith  wrote:

> Actually, scratch that, its not even JUST a matter of convenience. A
>> simple evaluation in your developer console will tell you that this
>> currently evaluates inconveniently (I am avoiding the term "incorrectly"
>> here because it is not theoretically incorrect if we consider these
>> evaluations left associative):
>>
>
> Since this proposal would change the semantics of existing valid programs,
> it would be a breaking change.  And breaking changes aren't really
> "allowed" (breaking the web and all that).
>
>
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Fix Left-Associative Compound Conditional Statements!!

[Kevin Smith]

>
> Actually, scratch that, its not even JUST a matter of convenience. A
> simple evaluation in your developer console will tell you that this
> currently evaluates inconveniently (I am avoiding the term "incorrectly"
> here because it is not theoretically incorrect if we consider these
> evaluations left associative):
>

Since this proposal would change the semantics of existing valid programs,
it would be a breaking change.  And breaking changes aren't really
"allowed" (breaking the web and all that).
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss

Re: Exponentiation operator precedence

[Brendan Eich]

[Apologies for resending, trying to fix formatting of grammar excerpts. /be]

Quick update from TC39 yesterday where Rick and I presented the Stage 3 
Exponentiation Operator proposal:


http://rwaldron.github.io/exponentiation-operator/

The current spec, revised to match precedent from all known programming 
languages that have exponentiation operators, binds


-x^y = -(x^y )

and not

-x^y = (-x)^y

as the original proposal specified. These examples use Math notation, 
but the proposed exponentiation operator is infix ** of course. And 
that's the source of trouble for this proposal.


The problem is, however rare unary minus before an exponentiation 
expression may be, the lack of superscript-with-smaller-font sugests 
that - binds tighter than **. And indeed apart from dot (a special form 
whose right operand must be a lexical identifier-name) and square 
brackets (which isn't an infix operator per se), unary operators bind 
tighter than binary in JS as in C and other C-derived languages.


Yehuda suggested that exponentiation was "cargo-culted" from Math into 
Fortran, and then into other languages, without considering the 
notational shift and the apparent precedence inversion. I don't know the 
history, but it's plausible, and numerics folks probably would not 
expect unary - to bind tighter than exponentiation. But JS programmers 
may see -x and especially -2 as a tighter expression, if not a single 
lexeme, than any expression joined by infix **.


We debated the options, which I think are four in number:

1. Give up because the proposal has hit a "wall of confusion".

2. Stick with the current spec,

3. Go back to the old spec, which flouts precedent.

4. Make unparenthesized exponentiation expression as operand of unary 
operators an early error.


I came up with (4) late in the day, and it didn't get a fair hearing. 
Before I wrote it up on the board, I asked for a straw poll (those can 
bite back by forcing people onto a bandwagon, as Dave Herman pointed 
out) on (1-3). The poll favored (2), with notable but minority positions 
for (1) and (3).


The grammar change needed for (4) is trivial. Instead of

UnaryExpression_[Yield] :
IncrementExpression_[?Yield]
delete UnaryExpression_[?Yield]
void UnaryExpression_[?Yield]
typeof UnaryExpression_[?Yield]
+ UnaryExpression_[?Yield]
- UnaryExpression_[?Yield]
~ UnaryExpression_[?Yield]
!UnaryExpression_[?Yield]
IncrementExpression_[?Yield] ** UnaryExpression_[?Yield]

we factor to require parentheses around the last right-hand side if it 
is an operand of a unary operator:


UnaryExpression_[Yield] :
SimpleUnaryExpression_[?Yield]
IncrementExpression_[?Yield] ** UnaryExpression_[?Yield]

SimpleUnaryExpression_[Yield] :
IncrementExpression_[?Yield]
delete SimpleUnaryExpression_[?Yield]
void SimpleUnaryExpression_[?Yield]
typeof SimpleUnaryExpression_[?Yield]
+ SimpleUnaryExpression_[?Yield]
- SimpleUnaryExpression_[?Yield]
~ SimpleUnaryExpression_[?Yield]
!SimpleUnaryExpression_[?Yield]

(It would be nice to rename non-terminals like so: 
s/\/ExponentiationExpression/g; 
s/\/UnaryExpression/g where \<\> are left and 
right word boundaries -- but I'm leaving this out for now since it 
touches more of the spec and is merely a nominal change.)


Thus one may write

let z = K - x**y;

without having to parenthesize unduly, but one cannot write

let z = -x ** y;

The user is forced by an early error to write either (-x)**y or -(x**y).

The early error stops parsing with a thrown SyntaxError.

It seems to me (4) wins and rescues the proposal at stage 3 from 
suffering a loss of consensus. Comments welcome.


/be

Jason Orendorff wrote:

Don't rely on github searches to turn up representative examples. It
doesn't work that well. Here's my educated guess as to how ** will be
used.

The most common use will be to square numbers.

 a²
 a**2
 Math.pow(a, 2)
 a.pow(2)

Currently you might write `a * a`, which is kind of lame.

So where's the benefit? If this trivial thing is the most common use
of exponentation, why bother?

The ability to look at an expression and understand it at a glance is
a big deal.

 x² + y²>  limit
 x**2 + y**2>  limit
 Math.pow(x, 2) + Math.pow(y, 2)>  limit
 x.pow(2) + y.pow(2)>  limit

A big big deal. It's the reason we have arithmetic operators in JS in
the first place.

Exponentiation is common when computing easing functions, curves for
graphics, interest, simulations, random stuff in games. Nth roots are
fairly common too (`apr**(1/12)`). In all of these cases, the user is
doing the same thing: translating a mathematical formula they wish to
use from "math" to JS. It is not extra hard to translate such a
formula using Math.pow(), but it is harder to read once you're done.
You have to mentally translate back to "math".

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

Re: Exponentiation operator precedence

[Brendan Eich]

Quick update from TC39 yesterday where Rick and I presented the Stage 3 
Exponentiation Operator proposal:


http://rwaldron.github.io/exponentiation-operator/

The current spec, revised to match precedent from all known programming 
languages that have exponentiation operators, binds


-x^y = -(x^y )

and not

-x^y = (-x)^y

as the original proposal specified. These examples use Math notation, 
but the proposed exponentiation operator is infix ** of course. And 
that's the source of trouble for this proposal.


The problem is, however rare unary minus before an exponentiation 
expression may be, the lack of superscript-with-smaller-font sugests 
that - binds tighter than **. And indeed apart from dot (a special form 
whose right operand must be a lexical identifier-name) and square 
brackets (which isn't an infix operator per se), unary operators bind 
tighter than binary in JS as in C and other C-derived languages.


Yehuda suggested that exponentiation was "cargo-culted" from Math into 
Fortran, and then into other languages, without considering the 
notational shift and the apparent precedence inversion. I don't know the 
history, but it's plausible, and numerics folks probably would not 
expect unary - to bind tighter than exponentiation. But JS programmers 
may see -x and especially -2 as a tighter expression, if not a single 
lexeme, than any expression joined by infix **.


We debated the options, which I think are four in number:

1. Give up because the proposal has hit a "wall of confusion".

2. Stick with the current spec,

3. Go back to the old spec, which flouts precedent.

4. Make unparenthesized exponentiation expression as operand of unary 
operators an early error.


I came up with (4) late in the day, and it didn't get a fair hearing. 
Before I wrote it up on the board, I asked for a straw poll (those can 
bite back by forcing people onto a bandwagon, as Dave Herman pointed 
out) on (1-3). The poll favored (2), with notable but minority positions 
for (1) and (3).


The grammar change needed for (4) is trivial. Instead of

UnaryExpression_[Yield] :
IncrementExpression_[?Yield]
delete UnaryExpression_[?Yield]
void UnaryExpression_[?Yield]
typeof UnaryExpression_[?Yield]
+ UnaryExpression_[?Yield]
- UnaryExpression_[?Yield]
~ UnaryExpression_[?Yield]
!UnaryExpression_[?Yield]
IncrementExpression_[?Yield] ** UnaryExpression_[?Yield]

we factor to require parentheses around the last right-hand side if it 
is an operand of a unary operator:


UnaryExpression_[Yield] :
SimpleUnaryExpression_[?Yield]
IncrementExpression_[?Yield] ** UnaryExpression_[?Yield]

SimpleUnaryExpression_[Yield] :
IncrementExpression_[?Yield]
delete SimpleUnaryExpression_[?Yield]
void SimpleUnaryExpression_[?Yield]
typeof SimpleUnaryExpression_[?Yield]
+ SimpleUnaryExpression_[?Yield]
- SimpleUnaryExpression_[?Yield]
~ SimpleUnaryExpression_[?Yield]
!SimpleUnaryExpression_[?Yield]

(It would be nice to rename non-terminals like so: 
s/\/ExponentiationExpression/g; 
s/\/UnaryExpression/g where \<\> are left and 
right word boundaries -- but I'm leaving this out for now since it 
touches more of the spec and is merely a nominal change.)


Thus one may write

let z = K - x**y;

without having to parenthesize unduly, but one cannot write

let z = -x ** y;

The user is forced by an early error to write either (-x)**y or -(x**y).

The early error stops parsing with a thrown SyntaxError.

It seems to me (4) wins and rescues the proposal at stage 3 from 
suffering a loss of consensus. Comments welcome.


/be

Jason Orendorff wrote:

Don't rely on github searches to turn up representative examples. It
doesn't work that well. Here's my educated guess as to how ** will be
used.

The most common use will be to square numbers.

 a²
 a**2
 Math.pow(a, 2)
 a.pow(2)

Currently you might write `a * a`, which is kind of lame.

So where's the benefit? If this trivial thing is the most common use
of exponentation, why bother?

The ability to look at an expression and understand it at a glance is
a big deal.

 x² + y²>  limit
 x**2 + y**2>  limit
 Math.pow(x, 2) + Math.pow(y, 2)>  limit
 x.pow(2) + y.pow(2)>  limit

A big big deal. It's the reason we have arithmetic operators in JS in
the first place.

Exponentiation is common when computing easing functions, curves for
graphics, interest, simulations, random stuff in games. Nth roots are
fairly common too (`apr**(1/12)`). In all of these cases, the user is
doing the same thing: translating a mathematical formula they wish to
use from "math" to JS. It is not extra hard to translate such a
formula using Math.pow(), but it is harder to read once you're done.
You have to mentally translate back to "math".

-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

Fwd: Fix Left-Associative Compound Conditional Statements!!

[Joseph Groseclose]

## Left-Associative Compound Conditional Statements
I would like the ability to compare many values in compound. As I do not
see any real reason to avoid this, here is my proposal:

Following [this document](
http://yehudakatz.com/2011/09/13/a-proposal-for-es-next-proposals/) (thanks
@wykatz)

### What problem are we solving:
Often, it makes it easier and more convenient to compare values in a range
as opposed to comparing one to another and that value to even another. In
order to avoid this, JavaScript could add the ability to "chain" many
comparators, failing after the first inequality that is falsy.

### Provide Non-Trivial Example Code Showing the Problem:
For the remainder of this issue/request, I will be using (almost
exclusively) the "<" comparator, but any normal operators should work with
this proposal, including but not limited to:
* ==
* ===
* >
* <
* >=
* <=
* yada yada yada (not an operator)

Two examples:
```javascript
let foo = 1,
bar = 2,
baz = 3;
if (foo < bar && bar < baz) {
// ...do something!
}
```
While vaguely trivial, this snippet demonstrates the easiest way to
accurately compare these three values in a basic conditional. We have to
compare either the first two values and the second to values serially or in
parallel.

Likewise (and slightly less trivial):
```javascript
let arr = [ 'foo', 'bar', 'baz' ];
for (var i = 0; i < arr.length; ++i) {
// do something...
if (i > 1) {
 break;
}
}
```
The above illustrates an example where we want to iterate in a range. There
are several solutions to this (including a compound condition in the `for`
statement, cloning and slicing, or reversing the array and setting `i`
greater than zero), but this is even less convenient than the original
example!

### Show How the Example Code is Improved With the Proposal:
Now, we only have two left-associative conditions to evaluate as opposed to
three
```javascript
let foo = 1,
bar = 2,
baz = 3;
if (foo < bar < baz) {
// ...do something!
}
```

We have saved ourselves the trouble of including a good deal of logic in
our simple `for` loop as well:
```javascript
let arr = [ 'foo', 'bar', 'baz' ];
for (let i = 0, y = 2; i < arr.length < y; ++i) {
// do something...
}
```

What are Alternate ES3 (or ES5) Solutions to the Same Problem?:
I've included some solutions to how this can be avoided, it is worth noting
in this section that this is not so much about this situation being
unavoidable so much as it is a ~~matter of convenience~~.

Actually, scratch that, its not even JUST a matter of convenience. A simple
evaluation in your developer console will tell you that this currently
evaluates inconveniently (I am avoiding the term "incorrectly" here because
it is not theoretically incorrect if we consider these evaluations left
associative):
```javascript
1 < 2 < 3 // true where...
true < 3 // true...because
+true // 1
1 < 3 // true
```
Bear in mind that this is not a catch-all definition of this behavior:
```javascript
false === false == false // false (wut?)
```

### If the Proposal is For New Syntax, What if Anything Does it Desugar To?
The desugaring is shown above, but the concatenation of conditionals can be
converted into their non-concatenated equivalents:
```javascript
(1 < 2 < 3) === (1< 2 & 2 < 3) // Not a typo
```

### If New Syntax, Can it Be Compiled to ES3 (or ES5)?
Absolutely, in the same way it has been outlined above

### Does the Proposal Change any Existing Semantics?
I'm not entirely sure this is semantic (because the comparators of any two
values should evaluate in the same way they always have), but it is worth
noting in this section that any two values should work with compound
conditionals, not just numbers. For example,
```javascript
[] == [] === []
```
should fail comparison.

I realize this effectively makes `===` a silver bullet in compound
conditional statements, but I can't see any other way this would work.

Please let me know if there is any more context or detail I can provide, or
whether there are considerations I have not made.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss