

I would expect `2**3` to return 8, or `2**2 == 4`, since it should be like `(2**3)`
Firefox gives a clearer error then Chrome with: > SyntaxError: unparenthesized unary expression can't appear on the lefthand side of '**'
Is there a reason for this restriction? Python does it `2**3` fine
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


Cyril Auburtin schrieb:
> I would expect `2**3` to return 8, or `2**2 == 4`, since it should be
> like `(2**3)`
You would, others would not. 2 ** 2 clearly should return 4, shouldn't it?
> Is there a reason for this restriction? Python does it `2**3` fine
Because of the ambiguity it has been decided to make it a syntax error
if the two operators are used together. If you want `(2**3)`, you have
to write it like that, and if you want `(2)**3` you have to write it
explicitly as well.
See https://esdiscuss.org/topic/exponentiationoperatorprecedence for
the full discussion.
 Bergi
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


Ah, ok, a bit sad because all more scientific languages, and python too, all math books, all will use `e^3` for meaning `(e^3)` (^ or **), because it's just `exp(3)` or `pow(E, 3)`
and `(1)^n` otherwise, when we want to take the signs with.
If you wanted to avoid any confusion you could have forbidden `2**2**3` too because it's not obvious it's right associative
But ok, thanks for the explanation.
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


On Fri, Oct 14, 2016 at 7:31 AM Cyril Auburtin < [hidden email]> wrote: I would expect `2**3` to return 8, or `2**2 == 4`, since it should be like `(2**3)`
This was discussed extensively during the design process and determined that requiring user code to be explicit about its intention was the only sane design.
Rick
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


Here's some more specific notes: On Fri, Oct 14, 2016 at 7:31 AM Cyril Auburtin < [hidden email]> wrote: I would expect `2**3` to return 8, or `2**2 == 4`, since it should be like `(2**3)`
Math.pow(2, 3) === 8 Math.pow(2, 2) === 4
To get 4: Math.pow(2, 2)
Firefox gives a clearer error then Chrome with: > SyntaxError: unparenthesized unary expression can't appear on the lefthand side of '**'
That's correct.
Is there a reason for this restriction? Python does it `2**3` fine
Python is also inconsistent:
>>> pow(2, 2) 4 >>> 2 ** 2 4 >>>
Whereas, JavaScript is very consistent:
$ js js> (2 ** 2) 4 js> Math.pow(2, 2) 4 js> (2) ** 2 4 js> Math.pow(2, 2) 4 js>
Rick
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


> Le 14 oct. 2016 à 16:52, Rick Waldron < [hidden email]> a écrit :
>
> Python is also inconsistent:
>
> >>> pow(2, 2)
> 4
> >>> 2 ** 2
> 4
> >>>
This is not inconsistency, but that follows from operator precedence rules (those used in mathematics, not in C).
In the same vein, you have `pow(1+1, 2) == 4` but `1+1 ** 2 == 2`, because the latter is interpreted as `1+(1 ** 2)`.
—Claude
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


If 2 ** 2 returned me 4 in JS I would be confused.
JS is not a math language, it's a programming language. We have basic math operations on its syntax and that's fine.
> In the same vein, you have `pow(1+1, 2) == 4` but `1+1 ** 2 == 2`, because the latter is interpreted as `1+(1 ** 2)`. Where is this going to? Am I supposed to read the `1+1 ** 2 == 2` is a sugar for `pow(1+1, 2)`? that's not my reading.

Python does not follow a standard implemented in many different implementations governed by different ppl and orgs. Any behaviour, even the unexpected, becomes a feature, it's an easy field and canvas. I'm glad JS aims for a consistent and unambiguous path, even if that can't make everyone loving the syntax.
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


I must say throwing here, instead of relying on math dictated operators precedence looks really bad.
It's very surprising to those well experienced with the language, and totally inconsistent with how operators worked so far (there is no previous case where one will throw for similar reason).
Also argument that it's inconsistent with Math.pow(2, 2), is total miss in my eyes.
I believe to most programmers `Math.pow(2, 2)`, translates to `(2)**(2)` and not to `2**2`,
same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b : c)**(2)` and not to `a ? b : c**2`


It's quite simple (as has already been stated): some people expect `x ** y` to be `(x ** y)`. Some expect it to be `(x) ** y`.
The early SyntaxError ensures that nobody is confused  programmers will immediately add parens to disambiguate.
Avoiding a potential footgun for the next 50 years, at the insignificant cost of adding two characters so that it parses seems like a very cheap price to pay.
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


There are many other cases when with no parens involved, people have different expectations on the outcome.
If expression looks ambigous the actual result always depends on operators precedence, it's how language worked for years, and I don't remember any big problems due to that.
Jordan Harband wrote
It's quite simple (as has already been stated): some people expect `x **
y` to be `(x ** y)`. Some expect it to be `(x) ** y`.
The early SyntaxError ensures that nobody is confused  programmers will
immediately add parens to disambiguate.
Avoiding a potential footgun for the next 50 years, at the insignificant
cost of adding two characters so that it parses seems like a very cheap
price to pay.
On Tue, Oct 18, 2016 at 12:20 AM, medikoo < [hidden email]>
wrote:
> I must say throwing here, instead of relying on math dictated operators
> precedence looks really bad.
> It's very surprising to those well experienced with the language, and
> totally inconsistent with how operators worked so far (there is no previous
> case where one will throw for similar reason).
>
> Also argument that it's inconsistent with Math.pow(2, 2), is total miss in
> my eyes.
> I believe to most programmers `Math.pow(2, 2)`, translates to `(2)**(2)`
> and not to `2**2`,
> same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b :
> c)**(2)` and not to `a ? b : c**2`
>
>
>
>
> 
> View this message in context: http://mozilla.6506.n7.nabble.
> com/Poweroperatorwhydoes23throwstp359609p359731.html
> Sent from the Mozilla  ECMAScript 4 discussion mailing list archive at
> Nabble.com.
> _______________________________________________
> esdiscuss mailing list
> [hidden email]> https://mail.mozilla.org/listinfo/esdiscuss>
_______________________________________________
esdiscuss mailing list
[hidden email]https://mail.mozilla.org/listinfo/esdiscuss


If tc39 wanted to implement it one way or the other, they would indeed
use precedence. The problem is that the precedence of unary '' vs
binary '**' is ambiguous *between different people's heads*  not just
a little, but a lot. So whichever precedence you pick, some people will
be very surprised. It will be *obviously* wrong to some people, and
obviously correct to others.
No matter how good your mechanism is, it can't fix a policy problem.
On 10/18/2016 01:05 AM, medikoo wrote:
> There are many other cases when with no parens involved, people have
> different expectations on the outcome.
> If expression looks ambigous the actual result always depends on operators
> precedence, it's how language worked for years, and I don't remember any big
> problems due to that.
>
>
> Jordan Harband wrote
>> It's quite simple (as has already been stated): some people expect `x **
>> y` to be `(x ** y)`. Some expect it to be `(x) ** y`.
>>
>> The early SyntaxError ensures that nobody is confused  programmers will
>> immediately add parens to disambiguate.
>>
>> Avoiding a potential footgun for the next 50 years, at the insignificant
>> cost of adding two characters so that it parses seems like a very cheap
>> price to pay.
>>
>> On Tue, Oct 18, 2016 at 12:20 AM, medikoo <
>> medikoo+mozilla.org@
>> >
>> wrote:
>>
>>> I must say throwing here, instead of relying on math dictated operators
>>> precedence looks really bad.
>>> It's very surprising to those well experienced with the language, and
>>> totally inconsistent with how operators worked so far (there is no
>>> previous
>>> case where one will throw for similar reason).
>>>
>>> Also argument that it's inconsistent with Math.pow(2, 2), is total miss
>>> in
>>> my eyes.
>>> I believe to most programmers `Math.pow(2, 2)`, translates to
>>> `(2)**(2)`
>>> and not to `2**2`,
>>> same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b :
>>> c)**(2)` and not to `a ? b : c**2`
>>>
>>>
>>>
>>>
>>> 
>>> View this message in context: http://mozilla.6506.n7.nabble.
>>> com/Poweroperatorwhydoes23throwstp359609p359731.html
>>> Sent from the Mozilla  ECMAScript 4 discussion mailing list archive at
>>> Nabble.com.
>>> _______________________________________________
>>> esdiscuss mailing list
>>>
>> esdiscuss@
>>> https://mail.mozilla.org/listinfo/esdiscuss>>>
>> _______________________________________________
>> esdiscuss mailing list
>> esdiscuss@
>> https://mail.mozilla.org/listinfo/esdiscuss>
>
>
>
> 
> View this message in context: http://mozilla.6506.n7.nabble.com/Poweroperatorwhydoes23throwstp359609p359733.html> Sent from the Mozilla  ECMAScript 4 discussion mailing list archive at Nabble.com.
> _______________________________________________
> esdiscuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/esdiscuss_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


ES is already not free from such cases, e.g. `!'property' in object` will also not resolve as most will expect.
I understand and agree that case is ambigous and is problematic. It just feels very controversial to me that it was decided that this case will be handled differently than others that share exactly same problem.
For those who are not aware of all such quirks/inconsistences it leaves feeling that language is unpredictable in its behaviors.
On 10/18/2016 01:05 AM, medikoo wrote:
> There are many other cases when with no parens involved, people have
> different expectations on the outcome.
> If expression looks ambigous the actual result always depends on operators
> precedence, it's how language worked for years, and I don't remember any big
> problems due to that.
>
>
> Jordan Harband wrote
>> It's quite simple (as has already been stated): some people expect `x **
>> y` to be `(x ** y)`. Some expect it to be `(x) ** y`.
>>
>> The early SyntaxError ensures that nobody is confused  programmers will
>> immediately add parens to disambiguate.
>>
>> Avoiding a potential footgun for the next 50 years, at the insignificant
>> cost of adding two characters so that it parses seems like a very cheap
>> price to pay.
>>
>> On Tue, Oct 18, 2016 at 12:20 AM, medikoo <
>> medikoo+mozilla.org@
>> >
>> wrote:
>>
>>> I must say throwing here, instead of relying on math dictated operators
>>> precedence looks really bad.
>>> It's very surprising to those well experienced with the language, and
>>> totally inconsistent with how operators worked so far (there is no
>>> previous
>>> case where one will throw for similar reason).
>>>
>>> Also argument that it's inconsistent with Math.pow(2, 2), is total miss
>>> in
>>> my eyes.
>>> I believe to most programmers `Math.pow(2, 2)`, translates to
>>> `(2)**(2)`
>>> and not to `2**2`,
>>> same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b :
>>> c)**(2)` and not to `a ? b : c**2`
>>>
>>>
>>>
>>>
>>> 
>>> View this message in context: http://mozilla.6506.n7.nabble.
>>> com/Poweroperatorwhydoes23throwstp359609p359731.html
>>> Sent from the Mozilla  ECMAScript 4 discussion mailing list archive at
>>> Nabble.com.
>>> _______________________________________________
>>> esdiscuss mailing list
>>>
>> esdiscuss@
>>> https://mail.mozilla.org/listinfo/esdiscuss>>>
>> _______________________________________________
>> esdiscuss mailing list
>> esdiscuss@
>> https://mail.mozilla.org/listinfo/esdiscuss>
>
>
>
> 
> View this message in context: http://mozilla.6506.n7.nabble.com/Poweroperatorwhydoes23throwstp359609p359733.html> Sent from the Mozilla  ECMAScript 4 discussion mailing list archive at Nabble.com.
> _______________________________________________
> esdiscuss mailing list
> [hidden email]> https://mail.mozilla.org/listinfo/esdiscuss_______________________________________________
esdiscuss mailing list
[hidden email]https://mail.mozilla.org/listinfo/esdiscuss


It's a committeecompromise grammar hack.
ES is already not free from such cases, e.g. `!'property' in object` will
also not resolve as most will expect.
I understand and agree that case is ambigous and is problematic. It just
feels very controversial to me that it was decided that this case will be
handled differently than others that share exactly same problem.
For those who are not aware of all such quirks/inconsistences it leaves
feeling that language is unpredictable in its behaviors.
On 10/18/2016 01:05 AM, medikoo wrote:
> There are many other cases when with no parens involved, people have
> different expectations on the outcome.
> If expression looks ambigous the actual result always depends on operators
> precedence, it's how language worked for years, and I don't remember any
> big
> problems due to that.
>
>
> Jordan Harband wrote
>> It's quite simple (as has already been stated): some people expect `x **
>> y` to be `(x ** y)`. Some expect it to be `(x) ** y`.
>>
>> The early SyntaxError ensures that nobody is confused  programmers will
>> immediately add parens to disambiguate.
>>
>> Avoiding a potential footgun for the next 50 years, at the insignificant
>> cost of adding two characters so that it parses seems like a very cheap
>> price to pay.
>>
>> On Tue, Oct 18, 2016 at 12:20 AM, medikoo <
>> medikoo+mozilla.org@
>> >
>> wrote:
>>
>>> I must say throwing here, instead of relying on math dictated operators
>>> precedence looks really bad.
>>> It's very surprising to those well experienced with the language, and
>>> totally inconsistent with how operators worked so far (there is no
>>> previous
>>> case where one will throw for similar reason).
>>>
>>> Also argument that it's inconsistent with Math.pow(2, 2), is total miss
>>> in
>>> my eyes.
>>> I believe to most programmers `Math.pow(2, 2)`, translates to
>>> `(2)**(2)`
>>> and not to `2**2`,
>>> same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b :
>>> c)**(2)` and not to `a ? b : c**2`
>>>
>>>
>>>
>>>
>>> 
>>> View this message in context: http://mozilla.6506.n7.nabble.
>>> com/Poweroperatorwhydoes23throwstp359609p359731.html
>>> Sent from the Mozilla  ECMAScript 4 discussion mailing list archive at
>>> Nabble.com.
>>> _______________________________________________
>>> esdiscuss mailing list
>>>
>> esdiscuss@
>>> https://mail.mozilla.org/listinfo/esdiscuss
>>>
>> _______________________________________________
>> esdiscuss mailing list
>> esdiscuss@
>> https://mail.mozilla.org/listinfo/esdiscuss
>
>
>
>
> 
> View this message in context:
> http://mozilla.6506.n7.nabble.com/Poweroperatorwhydoes23throwstp359609p359733.html
> Sent from the Mozilla  ECMAScript 4 discussion mailing list archive at
> Nabble.com.
> _______________________________________________
> esdiscuss mailing list
> esdiscuss@
> https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
esdiscuss@
https://mail.mozilla.org/listinfo/esdiscuss

View this message in context: http://mozilla.6506.n7.nabble.com/Poweroperatorwhydoes23throwstp359609p359853.html
Sent from the Mozilla  ECMAScript 4 discussion mailing list archive at Nabble.com.
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss
_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss


The existence of traps in the language is not an argument for adding other ones.
On the contrary, we must learn from previous problematic design decisions, in order not to repeat the same errors.
Also, the language feeling more quirky is less a severe issue than the language inducing to produce more bugs.
—Claude
> Le 20 oct. 2016 à 08:27, medikoo < [hidden email]> a écrit :
>
> ES is already not free from such cases, e.g. `!'property' in object` will
> also not resolve as most will expect.
>
> I understand and agree that case is ambigous and is problematic. It just
> feels very controversial to me that it was decided that this case will be
> handled differently than others that share exactly same problem.
>
> For those who are not aware of all such quirks/inconsistences it leaves
> feeling that language is unpredictable in its behaviors.
>
> On 10/18/2016 01:05 AM, medikoo wrote:
>> There are many other cases when with no parens involved, people have
>> different expectations on the outcome.
>> If expression looks ambigous the actual result always depends on operators
>> precedence, it's how language worked for years, and I don't remember any
>> big
>> problems due to that.
>>
>>
>> Jordan Harband wrote
>>> It's quite simple (as has already been stated): some people expect `x **
>>> y` to be `(x ** y)`. Some expect it to be `(x) ** y`.
>>>
>>> The early SyntaxError ensures that nobody is confused  programmers will
>>> immediately add parens to disambiguate.
>>>
>>> Avoiding a potential footgun for the next 50 years, at the insignificant
>>> cost of adding two characters so that it parses seems like a very cheap
>>> price to pay.
>>>
>>> On Tue, Oct 18, 2016 at 12:20 AM, medikoo <
>>> medikoo+mozilla.org@
>>> >
>>> wrote:
>>>
>>>> I must say throwing here, instead of relying on math dictated operators
>>>> precedence looks really bad.
>>>> It's very surprising to those well experienced with the language, and
>>>> totally inconsistent with how operators worked so far (there is no
>>>> previous
>>>> case where one will throw for similar reason).
>>>>
>>>> Also argument that it's inconsistent with Math.pow(2, 2), is total miss
>>>> in
>>>> my eyes.
>>>> I believe to most programmers `Math.pow(2, 2)`, translates to
>>>> `(2)**(2)`
>>>> and not to `2**2`,
>>>> same as `Math.pow(a ? b : c, 2)` intuitively translates to `(a ? b :
>>>> c)**(2)` and not to `a ? b : c**2`
>>>>
>>>>
>>>>
>>>>
>>>> 
>>>> View this message in context: http://mozilla.6506.n7.nabble.
>>>> com/Poweroperatorwhydoes23throwstp359609p359731.html
>>>> Sent from the Mozilla  ECMAScript 4 discussion mailing list archive at
>>>> Nabble.com.
>>>> _______________________________________________
>>>> esdiscuss mailing list
>>>>
>>> esdiscuss@
>>>> https://mail.mozilla.org/listinfo/esdiscuss>>>>
>>> _______________________________________________
>>> esdiscuss mailing list
>>> esdiscuss@
>>> https://mail.mozilla.org/listinfo/esdiscuss>>
>>
>>
>>
>> 
>> View this message in context:
>> http://mozilla.6506.n7.nabble.com/Poweroperatorwhydoes23throwstp359609p359733.html>> Sent from the Mozilla  ECMAScript 4 discussion mailing list archive at
>> Nabble.com.
>> _______________________________________________
>> esdiscuss mailing list
>> esdiscuss@
>> https://mail.mozilla.org/listinfo/esdiscuss>
>
> _______________________________________________
> esdiscuss mailing list
> esdiscuss@
> https://mail.mozilla.org/listinfo/esdiscuss>
>
>
>
>
> 
> View this message in context: http://mozilla.6506.n7.nabble.com/Poweroperatorwhydoes23throwstp359609p359853.html> Sent from the Mozilla  ECMAScript 4 discussion mailing list archive at Nabble.com.
> _______________________________________________
> esdiscuss mailing list
> [hidden email]
> https://mail.mozilla.org/listinfo/esdiscuss_______________________________________________
esdiscuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/esdiscuss

