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
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
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
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
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]
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
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
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
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
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
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 }
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
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
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 ===
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
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
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
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
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
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
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
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
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
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
24 matches
Mail list logo
