Re: Exponentiation operator precedence
because the right-side-up way to say that is: e - a * c Yeah, I was waiting for someone to point that out, after I hit send. : ) I should spend more time setting up a better examples... ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
x ** y ** z is easier to read/write than x.pow(y.pow(z))
That might be cherry picking. Trying to make up something a little more
complex:
a**b * -c**d + e
Math.pow(a, b) * -Math.pow(c, d) + e
a.pow(b) * -c.pow(d) + e
I don't have strong feelings on this issue, but the third option looks
pretty good to me. If we had some form of pipelining syntax (yet to be
proposed), then we could have:
let { pow } = Math;
a-pow(b) * -c-pow(d) + e;
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
You don't need to be a language guru to know which operation will be performed first, you can (and should) check an operator precedence and associativity table such as MDN's https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Operator_Precedence . Knowing operator precedence and associativity is very important when reading code written by others, and many projects use the no unnecessary parens linting rule. /fm On Thu, Aug 27, 2015 at 8:35 AM, Bill Frantz fra...@pwpconsult.com wrote: On 8/27/15 at 11:51 PM, niloy.monda...@gmail.com (Niloy Mondal) wrote: x ** y ** z is easier to read/write than x.pow(y.pow(z)) As a language guru, you know which operation will be performed first. As Joe programmer, I don't and I would need to write it as x ** (y ** z). With some operations, like +, the order doesn't matter and x + y + z is not confusing. Cheers - Bill --- Bill Frantz|We used to quip that password is the most common 408-356-8506 | password. Now it's 'password1.' Who said users haven't www.pwpconsult.com | learned anything about security? -- Bruce Schneier ___ 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
On Thu, Aug 27, 2015 at 9:04 AM, Kevin Smith zenpars...@gmail.com wrote: a**b * -c**d + e I don't think people use unary - like this very often. It's nothing to do with exponentiation. You don't see people write: a * -c + e because the right-side-up way to say that is: e - a * c -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Computed Property Name Shorthand Proposal
I'm usually lousy at interpreting the spec (yet here I go!), but I think
the behavior is explained here [1]:
PropertyDefinition[Yield] :
IdentifierReference[?Yield]
CoverInitializedName[?Yield]
PropertyName[?Yield] : AssignmentExpression[In, ?Yield]
MethodDefinition[?Yield]
PropertyName[Yield,GeneratorParameter] :
LiteralPropertyName
[+GeneratorParameter] ComputedPropertyName
[~GeneratorParameter] ComputedPropertyName[?Yield]
LiteralPropertyName :
IdentifierName
StringLiteral
NumericLiteral
ComputedPropertyName[Yield] :
[ AssignmentExpression[In, ?Yield] ]
There are aspects to that grammar that I don't fully grok yet, but your `{
[foo] }` example appears to be trying to combine the `IdentifierReference`
form (which *doesn't support* an `AssignmentExpression`) and the `PropertyName:
AssignmentExpression` form (which *requires* the `AssignmentExpression`).
In other words, all paths in that grammar that lead to a `
ComputedPropertyName` being valid also require the right-hand `
AssignmentExpression`.
[1]
http://people.mozilla.org/~jorendorff/es6-draft.html#sec-object-initializer
On Thu, Aug 27, 2015 at 12:25 PM, Kevin Smith zenpars...@gmail.com wrote:
I'd expect the following to work, given that the prop expression evaluates
to 'bar', and bar is in context.
var foo = 'bar'
var bar = 'ponyfoo'
var baz = { [foo] }
console.log(baz)
// - { bar: 'ponyfoo' }
Hmmm... I'm not sure I would expect any such thing. It seems like you're
proposing some kind of dynamic eval-ish variable binding lookup, which is
probably going to be a no-go.
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Jeremy Martin
661.312.3853
http://devsmash.com
@jmar777
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
On 08/27/2015 09:25 AM, Dean Tribble wrote: Ideally syntax proposals should include some frequency information to motivate any change. Is there an easy search to estimate the frequency of Math.pow? In my application codebase (financial app with only modest JS use), there are very few uses, and there are as many uses of Math.sin as there are of Math.pow. Frequency relative to what, though? If code that does nontrivial math is a very small proportion of total JS code, and yet the exponentiation operator makes that code much more readable, then what is the conclusion? I would argue that ** precedence confusion is irrelevant to code that isn't going to use Math.pow in the first place. So it's a question of whether ** is a big enough readability win in code that computes exponents. Anecdotally, my eyes caught on: -Math.pow(2,-10*a/1) (from a charting library) which makes me not want to have to review code where I'm worried about the precedence of exponentiation. I'd have to write that out: -2**(-10*a/1). That doesn't seem too bad. For myself, I do very much prefer Math.sqrt(a**2 + b**2) to Math.sqrt(Math.pow(a, 2) + Math.pow(b, 2)). The verbosity and uneven density of notation is really bothersome -- for any equation like the second one, I guarantee that I'll rewrite it on paper to figure out what it's saying. (Ok, maybe not for that specific formula, but even there I'll mentally render it.) I would not need to do so with the first one. Jumping between prefix and infix is jarring. Then again, I could make the same argument for Math.sqrt(a**2 + b**2) vs (a**2 + b**2) ** 0.5. And I don't like the second one much. But people don't interchange those when handwriting formulas, either. Math.sqrt(a.pow(2) + b.pow(2)) is an interesting middle point. I initially thought it struck the right balance, but seeing it written out, it still looks far inferior to me. A more complex example might help: a * (b - a)**(x - 1/2 * (b - a)**2) vs a * Math.pow(b - a, x - 1/2 * Math.pow(b - a, 2)) vs a * (b - a).pow(x - 1/2 * (b - a).pow(2)) For me, the middle one is a mess. I can't make sense of it, and I can't spot the common (b - a) expression at all. The first one is as readable as such formulas ever are when written out with ASCII text. The third one is somewhere in between. I can see the common (b - a), and perhaps if I got more used to seeing .pow I could mentally make use of it without writing it on paper, but for now I cannot. Part of the problem is that I can easily translate x**2 into x squared, but x.pow(2) is raising x to the power of 2. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
Anecdotal evidence via a quick github search https://github.com/search?l=JavaScriptp=1q=Math.pow+language%3AJavaScript+extension%3Ajsref=advsearchtype=Codeutf8=%E2%9C%93 A significant number of the usages are unit tests. Many others are repeats from popular libraries like D3. The most extreme use case I could find: y4ashida/ika/blob/master/js/culc_dence.js https://github.com/y4ashida/ika/blob/master/js/culc_dence.js On Thu, Aug 27, 2015 at 11:19 AM, Steve Fink sph...@gmail.com wrote: On 08/27/2015 09:25 AM, Dean Tribble wrote: Ideally syntax proposals should include some frequency information to motivate any change. Is there an easy search to estimate the frequency of Math.pow? In my application codebase (financial app with only modest JS use), there are very few uses, and there are as many uses of Math.sin as there are of Math.pow. Frequency relative to what, though? If code that does nontrivial math is a very small proportion of total JS code, and yet the exponentiation operator makes that code much more readable, then what is the conclusion? I would argue that ** precedence confusion is irrelevant to code that isn't going to use Math.pow in the first place. So it's a question of whether ** is a big enough readability win in code that computes exponents. Anecdotally, my eyes caught on: -Math.pow(2,-10*a/1) (from a charting library) which makes me not want to have to review code where I'm worried about the precedence of exponentiation. I'd have to write that out: -2**(-10*a/1). That doesn't seem too bad. For myself, I do very much prefer Math.sqrt(a**2 + b**2) to Math.sqrt(Math.pow(a, 2) + Math.pow(b, 2)). The verbosity and uneven density of notation is really bothersome -- for any equation like the second one, I guarantee that I'll rewrite it on paper to figure out what it's saying. (Ok, maybe not for that specific formula, but even there I'll mentally render it.) I would not need to do so with the first one. Jumping between prefix and infix is jarring. Then again, I could make the same argument for Math.sqrt(a**2 + b**2) vs (a**2 + b**2) ** 0.5. And I don't like the second one much. But people don't interchange those when handwriting formulas, either. Math.sqrt(a.pow(2) + b.pow(2)) is an interesting middle point. I initially thought it struck the right balance, but seeing it written out, it still looks far inferior to me. A more complex example might help: a * (b - a)**(x - 1/2 * (b - a)**2) vs a * Math.pow(b - a, x - 1/2 * Math.pow(b - a, 2)) vs a * (b - a).pow(x - 1/2 * (b - a).pow(2)) For me, the middle one is a mess. I can't make sense of it, and I can't spot the common (b - a) expression at all. The first one is as readable as such formulas ever are when written out with ASCII text. The third one is somewhere in between. I can see the common (b - a), and perhaps if I got more used to seeing .pow I could mentally make use of it without writing it on paper, but for now I cannot. Part of the problem is that I can easily translate x**2 into x squared, but x.pow(2) is raising x to the power of 2. ___ 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: Exponentiation operator precedence
Long-time esdiscuss lurker; hopefully this perspective is helpful. I think the problem here is that traditional mathematic notation uses visual cues to imply precedence that JS can't take advantage of. When -3 ** 2 is written out on paper, the 2 is very clearly grouped visually with the 3. In fact, the superscript almost makes the 2 feel like an appendage of the 3. That makes it more natural to read it as two items: the negative sign, and (3 ** 2). By contrast, when (-3 ** 2) is written out in code, the negative sign is way closer visually to the 3 than the 2 is, so I find myself instinctively pulling out a -3 first and reading the expression as (-3)**2. Treating -3 ** 2 as -(3 ** 2) seems technologically possible and mathematically sensible, but also like it's going against the grain of the human visual system. I think that's at least one reason to value the binary precedence should be lower than unary principle. The `Number.prototype.pow` approach might be an improvement, as it has the effect of mandating parentheses on some cases that might otherwise be confusing (e.g. x ** y ** z) and it offers most of the conciseness of **. But -x.pow(2) still feels unpredictable to me as an everyday programmer switching between languages. (Also, pow() requires an extra set of parentheses if I want to operate on a literal.) Maybe it's ok if the operator surprises some people in some cases, and the guidance will just become to use parentheses if you're unsure. That occasional uncertainty for the vast majority of JS programmers that aren't doing much exponentiation might be worth it if ** makes a minority of JS programmers much more productive. I don't know. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Assignment of global variables deleted by their RHS in strict mode
On Aug 27, 2015, at 1:03 AM, André Bargull wrote:
A fix for this would be in 8.1.1.4.5, insert between the current steps 4 and
5:
4.5 If S is true, then
a. Let stillHasBinding be ObjRec.HasBinding(N).
b. ReturnIfAbrupt(stillHasBinding).
c. If stillHasBinding is false, throw a ReferenceError exception.
I think the check should go into 8.1.1.2.5 SetMutableBinding. That way the
similar issue for object
environment records gets also fixed:
```
var scope = {x: 1};
with (scope) {
(function() {
use strict;
x = (delete scope.x, 2);
})();
}
```
Except for SpiderMonkey, all other engines tested (Edge, Nashorn, JSC, V8)
already throw a
ReferenceError for the above snippet. But that's probably because engines
don't implement the
'correct' Reference type semantics
(https://bugs.ecmascript.org/show_bug.cgi?id=4379).
- André
I think you are probably right. In which case it becomes step 2.5 in 8.1.1.2.5
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Computed Property Name Shorthand Proposal
I'd expect the following to work, given that the prop expression evaluates
to 'bar', and bar is in context.
var foo = 'bar'
var bar = 'ponyfoo'
var baz = { [foo] }
console.log(baz)
// - { bar: 'ponyfoo' }
Hmmm... I'm not sure I would expect any such thing. It seems like you're
proposing some kind of dynamic eval-ish variable binding lookup, which is
probably going to be a no-go.
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Computed Property Name Shorthand Proposal
I'd expect the following to work, given that the prop expression evaluates
to 'bar', and bar is in context.
var foo = 'bar'
var bar = 'ponyfoo'
var baz = { [foo] }
console.log(baz)
// - { bar: 'ponyfoo' }
The following works
var foo = 'bar'
var bar = 'ponyfoo'
var baz = { [foo]: bar }
console.log(baz)
// - { bar: 'ponyfoo' }
Sorry for not being quite spec-speak versed, this is my first message here.
Nico
github https://github.com/bevacqua · blog http://ponyfoo.com/ · twitter
https://twitter.com/nzgb · book http://bevacqua.io/buildfirst · career
http://careers.stackoverflow.com/bevacqua ·about http://bevacqua.io/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
Ideally syntax proposals should include some frequency information to motivate any change. Is there an easy search to estimate the frequency of Math.pow? In my application codebase (financial app with only modest JS use), there are very few uses, and there are as many uses of Math.sin as there are of Math.pow. Anecdotally, my eyes caught on: -Math.pow(2,-10*a/1) (from a charting library) which makes me not want to have to review code where I'm worried about the precedence of exponentiation. On Thu, Aug 27, 2015 at 7:32 AM, Kevin Smith zenpars...@gmail.com wrote: because the right-side-up way to say that is: e - a * c Yeah, I was waiting for someone to point that out, after I hit send. : ) I should spend more time setting up a better examples... ___ 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
On Thu, Aug 27, 2015 at 2:58 PM, Alexander Jones a...@weej.com wrote: Ethan is making my point far better than I did, and I agree completely about the issue of unary operators visually appearing more tightly bound than binary operators. At this point it seems fair to at least acknowledge the prospect of significant whitespace. ``` -x**2 === -(x ** 2) -x ** 2 === (-x) ** 2 ``` One kind of cost that I haven't seen mentioned (and is relevant re:whitespace) is the impact on minifiers and other tools that use JS as output, which have to deal with operator precedence/whitespace rules in quite complicated ways. There's a nice recent piece about precedence bugs in a minifier: https://zyan.scripts.mit.edu/blog/backdooring-js/ Making the creation and maintenance of systems like minifiers harder is a real cost worth bearing in mind when updating already-subtle existing rules. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
Ethan is making my point far better than I did, and I agree completely about the issue of unary operators visually appearing more tightly bound than binary operators. At this point it seems fair to at least acknowledge the prospect of significant whitespace. ``` -x**2 === -(x ** 2) -x ** 2 === (-x) ** 2 ``` On Thursday, August 27, 2015, Steve Fink sph...@gmail.com wrote: On 08/27/2015 11:20 AM, Ethan Resnick wrote: Long-time esdiscuss lurker; hopefully this perspective is helpful. I think the problem here is that traditional mathematic notation uses visual cues to imply precedence that JS can't take advantage of. When -3 ** 2 is written out on paper, the 2 is very clearly grouped visually with the 3. In fact, the superscript almost makes the 2 feel like an appendage of the 3. That makes it more natural to read it as two items: the negative sign, and (3 ** 2). By contrast, when (-3 ** 2) is written out in code, the negative sign is way closer visually to the 3 than the 2 is, so I find myself instinctively pulling out a -3 first and reading the expression as (-3)**2. If we're making ** bind tighter than unary -, then I would hope it would be written -3**2, not -3 ** 2. The latter is indeed deceptive. For me, x**y**z is rare enough that I don't really care if ** is right associative or nonassociative. Parentheses are part of the cost you have to pay for rendering things as plain text -- and yet, I see no reason not to make x**y**z just do the right thing. ___ 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
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
Re: Exponentiation operator precedence
On 08/27/2015 11:20 AM, Ethan Resnick wrote: Long-time esdiscuss lurker; hopefully this perspective is helpful. I think the problem here is that traditional mathematic notation uses visual cues to imply precedence that JS can't take advantage of. When -3 ** 2 is written out on paper, the 2 is very clearly grouped visually with the 3. In fact, the superscript almost makes the 2 feel like an appendage of the 3. That makes it more natural to read it as two items: the negative sign, and (3 ** 2). By contrast, when (-3 ** 2) is written out in code, the negative sign is way closer visually to the 3 than the 2 is, so I find myself instinctively pulling out a -3 first and reading the expression as (-3)**2. If we're making ** bind tighter than unary -, then I would hope it would be written -3**2, not -3 ** 2. The latter is indeed deceptive. For me, x**y**z is rare enough that I don't really care if ** is right associative or nonassociative. Parentheses are part of the cost you have to pay for rendering things as plain text -- and yet, I see no reason not to make x**y**z just do the right thing. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
On 08/27/2015 11:58, Alexander Jones wrote: Ethan is making my point far better than I did, and I agree completely about the issue of unary operators visually appearing more tightly bound than binary operators. At this point it seems fair to at least acknowledge the prospect of significant whitespace. ``` -x**2 === -(x ** 2) -x ** 2 === (-x) ** 2 ``` Take a look at the Fortress language ☺. But that one benefits from operators and syntax not limited to ASCII. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
Not to worry, the significant whitespace prospect was (I trust) a warding-off spell. Good of Waldemar to mention Fortress, too. JS, which as source is and will always be minified, indeed requires full-parsing minifiers, so one might naively still entertain the stated prospect. But it's a bad idea, since people minify (or just tidy by removing spaces) by hand. Keep warding off significant space! /be Joe Gibbs Politz wrote: On Thu, Aug 27, 2015 at 2:58 PM, Alexander Jonesa...@weej.com wrote: Ethan is making my point far better than I did, and I agree completely about the issue of unary operators visually appearing more tightly bound than binary operators. At this point it seems fair to at least acknowledge the prospect of significant whitespace. ``` -x**2 === -(x ** 2) -x ** 2 === (-x) ** 2 ``` One kind of cost that I haven't seen mentioned (and is relevant re:whitespace) is the impact on minifiers and other tools that use JS as output, which have to deal with operator precedence/whitespace rules in quite complicated ways. There's a nice recent piece about precedence bugs in a minifier: https://zyan.scripts.mit.edu/blog/backdooring-js/ Making the creation and maintenance of systems like minifiers harder is a real cost worth bearing in mind when updating already-subtle existing rules. ___ 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
JSDoc3-style operator to access property of prototype(s)
I've been using JSDoc 3 for documentation of JavaScript code for years now,
and it recently occurred to me that maybe the instanceMember namepath is
a candidate for inclusion in ECMAScript proper:
http://usejsdoc.org/about-namepaths.html
The # operator would effectively be syntax sugar for .prototype.
Some examples:
MyConstructor#method === MyConstructor.prototype.method; // true
class Child extends Parent {
method () {
// TODO: do something more than Parent would
return Parent#method.call(this);
// equivalent to Parent.prototype.method.call(this);
}
}
var args = Array#slice.call(arguments, 0);
Now, some of these examples may be anti-patterns in an ES2015 world, but I
wonder whether .prototype.foo is accessed frequently enough in enough code
(even post-ES2015) that there's some merit here.
For me, it would make argument wrangling and ES5 class code more
convenient, and it would also bring extra parity between my JSDoc content
and the actual code it documents.
Have all use cases for this idea already been squashed by ES2015? I realise
there is a high threshold for syntax changes.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: JSDoc3-style operator to access property of prototype(s)
class Child extends Parent {
method () {
// TODO: do something more than Parent would
return Parent#method.call(this);
This would be written return super.method();
var args = Array#slice.call(arguments, 0);
var args = Array.from(arguments);
(or rest params)
Have all use cases for this idea already been squashed by ES2015?
Yes, for the common use cases.
Kevin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Directed rounding
On 26.08.2015 23:37, Waldemar Horwat wrote: It doesn't make sense to encode a rounding mode such as round down into a value type. If you multiply it by -1, half of the time it will start doing the wrong thing. I agree: If this were implemented using a value type, then I'd envision myself converting between types all the time, since the rounding mode is indeed a property of the operation, not the value. User-definable value types would be very useful to build (multi-precision?) interval arithmetic on top of the directed rounding, though. Instead, you want functions that perform the primitive operations (+, -, *, /, sqrt, sin, etc.) in a rounding mode specified by the name of the function or perhaps a third parameter. I wonder which of these would be easier for engines to optimize. Detecting certain functions and inlining them during JIT compilation is already established, I think. Turning that third parameter into some machine-specific code is likely harder, but shouldn't be too hard as long as the third parameter is a literal or some constant. But this is my guessing, without too much knowledge about how intrinsics are actually handled during compilation. On the other hand, if that parameter might change, i.e. if you want to perform the same computation repeatedly with different rounding modes, then a parameter might be better than passing different combinations of functions as arguments. I can think of no real-world application where the same lengthy operation would be performed with different rounding modes, due to the sign change issues you already mentioned. But it might be worthwhile to investigate open source code which is using fesetround and friends to see whether I'm missing some application here. Greetings, Martin von Gagern signature.asc Description: OpenPGP digital signature ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
x ** y ** z is easier to read/write than x.pow(y.pow(z)) On Aug 27, 2015 8:51 AM, Mark S. Miller erig...@google.com wrote: On Wed, Aug 26, 2015 at 6:19 PM, Waldemar Horwat walde...@google.com wrote: On 08/26/2015 15:08, Mark S. Miller wrote: The force of that precedent is indeed what my objection is. The yield counter-example is interesting, but yield is an identifier not an operator symbol, and so does not as clearly fall within or shape operator expectations. If someone explains a compelling need for ** I would find that interesting. But until then... ** is a convenience, and that's the wrong criterion to apply here. If it were, then we wouldn't have useful conveniences like Math.cosh or arrow functions. I'd rather read a*x**3 + b*x**2 + c*x + d than a*Math.pow(x, 3) + b*Math.pow(x, 2) + c*x + d Ok, we have a benefit to evaluate. Brevity. With the example contrast between a*x**3 + b*x**2 + c*x + d and a*Math.pow(x, 3) + b*Math.pow(x, 2) + c*x + d Let's also apply Alexander's suggestion a*x.pow(3) + b*x.pow(2) + c*x + d To help us compare for brevity, and because I'm too lazy to count, I'm sending it in a fixed width font. -- 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
Re: Exponentiation operator precedence
On 8/27/15 at 11:51 PM, niloy.monda...@gmail.com (Niloy Mondal) wrote: x ** y ** z is easier to read/write than x.pow(y.pow(z)) As a language guru, you know which operation will be performed first. As Joe programmer, I don't and I would need to write it as x ** (y ** z). With some operations, like +, the order doesn't matter and x + y + z is not confusing. Cheers - Bill --- Bill Frantz|We used to quip that password is the most common 408-356-8506 | password. Now it's 'password1.' Who said users haven't www.pwpconsult.com | learned anything about security? -- Bruce Schneier ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Assignment of global variables deleted by their RHS in strict mode
A fix for this would be in 8.1.1.4.5, insert between the current steps 4 and
5:
4.5 If S is true, then
a. Let stillHasBinding be ObjRec.HasBinding(N).
b. ReturnIfAbrupt(stillHasBinding).
c. If stillHasBinding is false, throw a ReferenceError exception.
I think the check should go into 8.1.1.2.5 SetMutableBinding. That way the
similar issue for object
environment records gets also fixed:
```
var scope = {x: 1};
with (scope) {
(function() {
use strict;
x = (delete scope.x, 2);
})();
}
```
Except for SpiderMonkey, all other engines tested (Edge, Nashorn, JSC, V8)
already throw a
ReferenceError for the above snippet. But that's probably because engines don't
implement the
'correct' Reference type semantics
(https://bugs.ecmascript.org/show_bug.cgi?id=4379).
- André
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
