Re: Exponentiation operator precedence
On Wed, Aug 26, 2015 at 1:03 PM, Thomas thomasjamesfos...@bigpond.com wrote: There's still the issue of exponentiation being right-associative. Unless ** becomes an operator which behaves differently as to how it would in a high school maths class, we're at an impasse. I'm not sure I follow. Exponentiation is right-associative in math, in the current ** proposal, and in every suggested update to it. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
On Wed, Aug 26, 2015 at 11:09 AM, Mark S. Miller erig...@google.com wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it would be 4. Either answer will surprise too many programmers. I just think the danger is not so great. Who's really going to be surprised that `-x**2` is negative? This follows not only other mainstream programming languages but a mathematical notation that has been in common use for hundreds of years and is taught to every high school algebra student. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Is the informative definition of [[Enumerate]] buggy?
On Aug 26, 2015, at 11:03 AM, Raul-Sebastian Mihăilă wrote:
In 9.1.11. it's specified that the iterator returned by the [[Enumerate]]
method iterates over String-valued keys. But the informative definition at
the end of 9.1.11. is based on whatever is returned by calling
Reflect.enumerate on the prototype of the current object, assuming that there
is such a prototype.
If the prototype is a proxy and it's enumerate trap returns an iterator that
yields other kind of values than strings, then our original object's
[[Enumerate]] method will give us non-string keys as well. And they can be
any kind of values, not only symbols.
And the prototype [[Enumerate]] could return the same value multiple times,
which would also be a violation of the normative requirments expressed in 9.1.11
The final if statement in the informative algorithm should probably be replaced
by:
```js
if (!visited.has(protoName) typeof protoName === string) {
visited.add(protoName);
yield protoName;
}
```
I opened a bug for this: https://bugs.ecmascript.org/show_bug.cgi?id=4531
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
On Aug 26, 2015, at 9:09 AM, Mark S. Miller wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it would be 4. Either answer will surprise too many programmers. By contrast, no one is confused by either -Math.pow(2, 2) or Math.pow(-2, 2). An of course the history includes many very popular languages that chose to not include an exponentiation operator. This is really a cost-benefits issue. Several of us have identified costs (complexity, cognitive, pedagogical, error hazards, etc.). What are the benefits of having such an operator? Are they sufficient to offset the cost of having it. Allen___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Directed rounding
I think the better idea would be related to value types (
http://www.slideshare.net/BrendanEich/value-objects2) which brendan is
working on for ES7.
I fuzzily recall rounding modes being used as an example in one of these
slide decks, perhaps I am misremembering.
At any rate, one option would be for round down float and round up
float to be separate value types. It seems broadly similar to your
proposal, except that you could use actual operators. The lower range in
an interval would be a round down float and the upper range a round up
float.
--scott
On Wed, Aug 26, 2015 at 12:01 PM, Martin von Gagern gag...@ma.tum.de
wrote:
Hello Scott,
Thanks for the comment!
On 26.08.2015 17:22, C. Scott Ananian wrote:
`fesetround` would be a terrible way for JavaScript to implement this,
I agree, the stateful nature of rounding mode is a pain, and should be
kept in a tightly closed locker. I was more thinking about a method
which sets the rounding mode to something specific, then performs one
particular operation in that mode before resetting the mode to default.
This would encapsulate the needed functionality without exposing its
stateful nature. Of course engines would be encouraged to detect
sequences of calls to such intrinsics, and to avoid the mode changes
between operations with the same mode. But that's just implementation
improvements for the sake of performance, once the semantics are there.
I believe there have been proposals to allow greater access to IEEE
floating point intrinsics, and I suspect they were better engineered for
modularity.
Better engineered than fesetround? That's easy, I think. Better
engineered than my post? Easy as well, since I kept it to the bare
minimum. My previous post was more detailed. See
https://esdiscuss.org/topic/directed-rounding or perhaps this example
from that post:
```
const down = Math.directedRounding(-Infinity);
const up = Math.directedRounding(+Infinity);
function interval(lo, hi) { this.lo = lo; this.hi = hi; }
interval.prototype.add = function(that) {
return new interval(down.add(this.lo, that.lo),
up.add(this.hi, that.hi));
}
```
Perhaps one of the other readers of this list remembers
enough details to give you a good citation.
I would welcome any pointers in this regard. Searching the Gmane
archives, I couldn't find any. Perhaps that was because many search term
combinations I could think of resulted in lots of messages dealing with
decimal arithmetic, one way or another.
Greetings,
Martin
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
On Tue, Aug 25, 2015 at 5:43 PM, Mark S. Miller erig...@google.com wrote: When the costs were minor, it was ok that the benefits were minor. The costs will probably still be minor if we just let Rick look at it and revise the proposal. What has happened here is - upon implementing the feature, we noticed a problem - we thought through it together and found possible solutions - we found other languages already use these solutions This seems like less turbulence than average for a new ES feature, even a minor one. Considering dropping the feature seems premature. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
Yehuda Katz cited an acronym taught when he was a wee lad learning algebra: PEMDAS (Parentheses, Exponentiation, Multiplication/Dviistion, Addition/Subtraction). Who else learned this? There's nothing sacrosanct about binary precedence being generally lower than unary. Consider the property access operators in JS. But the precedent to which all cited languages bow is Math and that's what programmers (mostly) study. I think you are making too much out of the local -x ** y case in light of this global argument. /be Mark S. Miller wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it would be 4. Either answer will surprise too many programmers. By contrast, no one is confused by either -Math.pow(2, 2) or Math.pow(-2, 2). ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it would be 4. Either answer will surprise too many programmers. By contrast, no one is confused by either -Math.pow(2, 2) or Math.pow(-2, 2). On Wed, Aug 26, 2015 at 9:00 AM, Jason Orendorff jason.orendo...@gmail.com wrote: On Tue, Aug 25, 2015 at 5:43 PM, Mark S. Miller erig...@google.com wrote: When the costs were minor, it was ok that the benefits were minor. The costs will probably still be minor if we just let Rick look at it and revise the proposal. What has happened here is - upon implementing the feature, we noticed a problem - we thought through it together and found possible solutions - we found other languages already use these solutions This seems like less turbulence than average for a new ES feature, even a minor one. Considering dropping the feature seems premature. -j -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Is the informative definition of [[Enumerate]] buggy?
In 9.1.11. it's specified that the iterator returned by the [[Enumerate]] method iterates over String-valued keys. But the informative definition at the end of 9.1.11. is based on whatever is returned by calling Reflect.enumerate on the prototype of the current object, assuming that there is such a prototype. If the prototype is a proxy and it's enumerate trap returns an iterator that yields other kind of values than strings, then our original object's [[Enumerate]] method will give us non-string keys as well. And they can be any kind of values, not only symbols. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
There's still the issue of exponentiation being right-associative. Unless ** becomes an operator which behaves differently as to how it would in a high school maths class, we're at an impasse. That said, ^ is usually the operator used for exponentiation outside programming languages when you need to express an equation in text. It could be made explicit that ** is a variant on 'exponentiation', but then maybe things are deviating from being useful. Thomas On 27 Aug 2015, at 3:28 AM, Brendan Eich bren...@mozilla.org wrote: Yehuda Katz cited an acronym taught when he was a wee lad learning algebra: PEMDAS (Parentheses, Exponentiation, Multiplication/Dviistion, Addition/Subtraction). Who else learned this? There's nothing sacrosanct about binary precedence being generally lower than unary. Consider the property access operators in JS. But the precedent to which all cited languages bow is Math and that's what programmers (mostly) study. I think you are making too much out of the local -x ** y case in light of this global argument. /be Mark S. Miller wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it would be 4. Either answer will surprise too many programmers. By contrast, no one is confused by either -Math.pow(2, 2) or Math.pow(-2, 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: Exponentiation operator precedence
Exponentiation is written in conventional mathematics as if it were a postfix unary operator, parameterised by a value written in superscript. IMO this puts it in a whole different class to binary operators where both operands are written equally. I don't see a ** b ** c as a good reflection of mathematical convention. Number.prototype.pow, on the other hand, would be fine. On Wednesday, August 26, 2015, Jason Orendorff jason.orendo...@gmail.com wrote: On Wed, Aug 26, 2015 at 1:03 PM, Thomas thomasjamesfos...@bigpond.com javascript:; wrote: There's still the issue of exponentiation being right-associative. Unless ** becomes an operator which behaves differently as to how it would in a high school maths class, we're at an impasse. I'm not sure I follow. Exponentiation is right-associative in math, in the current ** proposal, and in every suggested update to it. -j ___ es-discuss mailing list es-discuss@mozilla.org javascript:; https://mail.mozilla.org/listinfo/es-discuss ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Directed rounding
On 08/26/2015 13:12, C. Scott Ananian wrote: I think the better idea would be related to value types (http://www.slideshare.net/BrendanEich/value-objects2) which brendan is working on for ES7. I fuzzily recall rounding modes being used as an example in one of these slide decks, perhaps I am misremembering. At any rate, one option would be for round down float and round up float to be separate value types. It seems broadly similar to your proposal, except that you could use actual operators. The lower range in an interval would be a round down float and the upper range a round up float. 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. 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. This must be stateless, not carrying a rounding mode with a value or (even worse) in some global environment. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Assignment of global variables deleted by their RHS in strict mode
See the following test262 test:
https://github.com/tc39/test262/blob/master/test/language/expressions/assignment/S11.13.1_A5_T5.js
(and related tests with update / compound assignment).
In short, it is possible to have a Reference to a global variable which has
been deleted. Normally, bare assignments to undeclared variables in strict
mode cause ReferenceErrors. However, calling PutValue on a reference to a
global variable which has been deleted since the reference was created does
not throw a ReferenceError in strict mode, even though, *at the time of
writing*, that variable does not exist.
As far as I can tell, this is true in ES5 as well as ES6, but none of {V8,
SpiderMonkey, JavaScriptCore, Nashorn} get it right. This is consistent and
makes sense, but is it intentional?
___
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
Filed at https://bugs.ecmascript.org/show_bug.cgi?id=4532
On Wed, Aug 26, 2015 at 3:17 PM, Mark S. Miller erig...@google.com wrote:
On Wed, Aug 26, 2015 at 2:55 PM, Kevin Gibbons ke...@shapesecurity.com
wrote:
See the following test262 test:
https://github.com/tc39/test262/blob/master/test/language/expressions/assignment/S11.13.1_A5_T5.js
(and related tests with update / compound assignment).
In short, it is possible to have a Reference to a global variable which
has been deleted. Normally, bare assignments to undeclared variables in
strict mode cause ReferenceErrors. However, calling PutValue on a reference
to a global variable which has been deleted since the reference was created
does not throw a ReferenceError in strict mode, even though, *at the time
of writing*, that variable does not exist.
As far as I can tell, this is true in ES5 as well as ES6, but none of
{V8, SpiderMonkey, JavaScriptCore, Nashorn} get it right. This is
consistent and makes sense, but is it intentional?
Hmmm, interesting. It was not the intention of the strict mode design to
allow this to slip by without a thrown error. If we had explicitly
considered this issue during the early strict mode design, we definitely
would have made this a thrown error of some sort. ReferenceError sounds
good to me, but I can't say that we would not have decided on TypeError.
Either seems plausible enough.
I agree that the silent failure implied by the current spec is buggy.
Please file a bug against the ES6 spec. We should correct this at least in
the errata.
Thanks for raising this!
And thanks to André Bargull for writing that test case! I wish I was aware
of it earlier.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
On Wed, Aug 26, 2015 at 2:55 PM, Waldemar Horwat walde...@google.com wrote: On 08/26/2015 09:09, Mark S. Miller wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it would be 4. Either answer will surprise too many programmers. By contrast, no one is confused by either -Math.pow(2, 2) or Math.pow(-2, 2). The grammar concerns have been resolved nicely upthread, so I'm not sure what your objection is. The costs are no more significant than in the original proposal. ** now has the same precedence as unary operators and weaker than the increment operators, which matches what most other languages that support exponentiation do. There is precedence for unary operators not always binding tighter than binary. yield 3+4 is yield(3+4), not (yield 3)+4. 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... -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
On 08/26/2015 09:09, Mark S. Miller wrote: I don't get it. The conflict between * the history of ** in other languages, * the general pattern that unary binds tighter than binary seems unresolvable. By the first bullet, -2 ** 2 would be -4. By the second, it would be 4. Either answer will surprise too many programmers. By contrast, no one is confused by either -Math.pow(2, 2) or Math.pow(-2, 2). The grammar concerns have been resolved nicely upthread, so I'm not sure what your objection is. The costs are no more significant than in the original proposal. ** now has the same precedence as unary operators and weaker than the increment operators, which matches what most other languages that support exponentiation do. There is precedence for unary operators not always binding tighter than binary. yield 3+4 is yield(3+4), not (yield 3)+4. Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
Alexander Jones schrieb: Exponentiation is written in conventional mathematics as if it were a postfix unary operator, parameterised by a value written in superscript. IMO this puts it in a whole different class to binary operators where both operands are written equally. I don't see a ** b ** c as a good reflection of mathematical convention. I disagree. When in maths we write x sup y sup z /sup/sup, we mean x ^ (y ^ z). Which is exactly what `x ** y ** z` will do. And no, we never write x supy/sup supz/sup, if we wanted to express that we'd write x supy * z/sup (or often enough, with implicit multiplication, i.e. no * operator: x supy z/sup). If we'd want to express that in JS, it would by x ** (y * z). Number.prototype.pow, on the other hand, would be fine. You don't mean to use it like `x.pow(y).pow(z)`, do you? Sure, a function or method invocation is always explicit with parenthesis. But that's no improvement over the current `Math.pow`. Bergi ___ 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 Wed, Aug 26, 2015 at 2:55 PM, Kevin Gibbons ke...@shapesecurity.com
wrote:
See the following test262 test:
https://github.com/tc39/test262/blob/master/test/language/expressions/assignment/S11.13.1_A5_T5.js
(and related tests with update / compound assignment).
In short, it is possible to have a Reference to a global variable which
has been deleted. Normally, bare assignments to undeclared variables in
strict mode cause ReferenceErrors. However, calling PutValue on a reference
to a global variable which has been deleted since the reference was created
does not throw a ReferenceError in strict mode, even though, *at the time
of writing*, that variable does not exist.
As far as I can tell, this is true in ES5 as well as ES6, but none of {V8,
SpiderMonkey, JavaScriptCore, Nashorn} get it right. This is consistent and
makes sense, but is it intentional?
Hmmm, interesting. It was not the intention of the strict mode design to
allow this to slip by without a thrown error. If we had explicitly
considered this issue during the early strict mode design, we definitely
would have made this a thrown error of some sort. ReferenceError sounds
good to me, but I can't say that we would not have decided on TypeError.
Either seems plausible enough.
I agree that the silent failure implied by the current spec is buggy.
Please file a bug against the ES6 spec. We should correct this at least in
the errata.
Thanks for raising this!
And thanks to André Bargull for writing that test case! I wish I was aware
of it earlier.
--
Cheers,
--MarkM
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
Le 26 août 2015 à 00:43, Mark S. Miller erig...@google.com a écrit : When the costs were minor, it was ok that the benefits were minor. Given significant costs, we need to ask: While I don't have a strong opinion about the cost of the proposed modified grammar, I protest that the cost of the previous version wasn't anything near minor (although it was probably an oversight): having `-x**y` producing (literally) the opposite result of what is expected, and even only half of the time, is a high cost in terms of bugs produced and debugging man-hours lost. —Claude Why do we need ** ? What great benefit does it provide? If nothing compelling, then this proposal has lost consensus. On Tue, Aug 25, 2015 at 3:30 PM, Claude Pache claude.pa...@gmail.com mailto:claude.pa...@gmail.com wrote: Le 25 août 2015 à 03:22, Jason Orendorff jason.orendo...@gmail.com mailto:jason.orendo...@gmail.com a écrit : On Mon, Aug 24, 2015 at 7:24 PM, Jason Orendorff jason.orendo...@gmail.com mailto:jason.orendo...@gmail.com P.S. Admittedly it might be a good idea to rename UnaryExpression if we put a binary operator in there. -j RightAssociativeExpression? —Claude ___ es-discuss mailing list es-discuss@mozilla.org mailto:es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
I completely agree. My When the costs were minor refers to when we were not yet aware of the conflict. On Wed, Aug 26, 2015 at 12:19 AM, Claude Pache claude.pa...@gmail.com wrote: Le 26 août 2015 à 00:43, Mark S. Miller erig...@google.com a écrit : When the costs were minor, it was ok that the benefits were minor. Given significant costs, we need to ask: While I don't have a strong opinion about the cost of the proposed modified grammar, I protest that the cost of the previous version wasn't anything near minor (although it was probably an oversight): having `-x**y` producing (literally) the opposite result of what is expected, and even only half of the time, is a high cost in terms of bugs produced and debugging man-hours lost. —Claude Why do we need ** ? What great benefit does it provide? If nothing compelling, then this proposal has lost consensus. On Tue, Aug 25, 2015 at 3:30 PM, Claude Pache claude.pa...@gmail.com wrote: Le 25 août 2015 à 03:22, Jason Orendorff jason.orendo...@gmail.com a écrit : On Mon, Aug 24, 2015 at 7:24 PM, Jason Orendorff jason.orendo...@gmail.com P.S. Admittedly it might be a good idea to rename UnaryExpression if we put a binary operator in there. -j RightAssociativeExpression? —Claude ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Directed rounding
Hello! Would you consider providing intrinsic functions for directed rounding, to encapsulate the corresponding features of IEE 754 floating point computations (resp. the fesetround function of C99)? That would be useful for mathematical applications, in particular when implementing interval arithmetic for exact predicates. I wrote about this before, on June 20, but probably that post was way too verbose, since I didn't receive any reaction at all. So I'll keep the initial post short this time. Thanks for any comment, 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: Directed rounding
`fesetround` would be a terrible way for JavaScript to implement this, as it would allow a piece of code to affect the behavior of completely unrelated pieces of code by screwing with global rounding mode bits. That's not going to happen. I believe there have been proposals to allow greater access to IEEE floating point intrinsics, and I suspect they were better engineered for modularity. Perhaps one of the other readers of this list remembers enough details to give you a good citation. --scott On Wed, Aug 26, 2015 at 9:00 AM, Martin von Gagern gag...@ma.tum.de wrote: Hello! Would you consider providing intrinsic functions for directed rounding, to encapsulate the corresponding features of IEE 754 floating point computations (resp. the fesetround function of C99)? That would be useful for mathematical applications, in particular when implementing interval arithmetic for exact predicates. I wrote about this before, on June 20, but probably that post was way too verbose, since I didn't receive any reaction at all. So I'll keep the initial post short this time. Thanks for any comment, Martin von Gagern ___ 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: Cancelable promises proposal
On 8/3/15 8:15 PM, Glen Huang wrote: Ideally, if the same resolve reject callback combination is passed more than once, the same promise is always returned That's a backwards-incompatible change from what browsers are shipping, right? (I can't think of a use case where promises could stop to work, if promises were specced with this additional rule, but maybe I overlooked) As long as no one uses the promise as a key in a Map or anything else that relies on its object identity... Do you have a use case where the same callback will be passed to the same promise more than once? Not offhand, but I would be shocked if no one is doing it. -Boris ___ 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 26, 2015, at 3:17 PM, Mark S. Miller wrote:
On Wed, Aug 26, 2015 at 2:55 PM, Kevin Gibbons ke...@shapesecurity.com
wrote:
See the following test262 test:
https://github.com/tc39/test262/blob/master/test/language/expressions/assignment/S11.13.1_A5_T5.js
(and related tests with update / compound assignment).
In short, it is possible to have a Reference to a global variable which has
been deleted. Normally, bare assignments to undeclared variables in strict
mode cause ReferenceErrors. However, calling PutValue on a reference to a
global variable which has been deleted since the reference was created does
not throw a ReferenceError in strict mode, even though, *at the time of
writing*, that variable does not exist.
As far as I can tell, this is true in ES5 as well as ES6, but none of {V8,
SpiderMonkey, JavaScriptCore, Nashorn} get it right. This is consistent and
makes sense, but is it intentional?
Hmmm, interesting. It was not the intention of the strict mode design to
allow this to slip by without a thrown error. If we had explicitly considered
this issue during the early strict mode design, we definitely would have made
this a thrown error of some sort. ReferenceError sounds good to me, but I
can't say that we would not have decided on TypeError. Either seems plausible
enough.
I agree that the silent failure implied by the current spec is buggy. Please
file a bug against the ES6 spec. We should correct this at least in the
errata.
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.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
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 Waldemar ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
Not much, as far as I can tell. Engines do usually lower this, and redo the whole object when the shape changes, or an intrinsic no longer applies. V8 has a MathPow intrinsic, and I believe SpiderMonkey has similar. On Wed, Aug 26, 2015, 23:45 Jordan Harband ljh...@gmail.com wrote: Is there also perhaps a potential performance/static analysis benefit in having it be syntax, rather than a builtin function? `Math.pow` can be overwritten, and varies per-realm, but `**` can not and does not. On Wed, Aug 26, 2015 at 8:21 PM, 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 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Cancelable promises proposal
IMO promises should reject if they are cancelled. The same method that gave you the Promise (for example, an AJAX API) can give you a capability to cancel the Promise, ie cancel the pending network operation and reject the Promise (rejecting is a no-op if the operation races with cancellation and manages to resolve first, naturally). I'm not opposed to setting up a defacto API for the cancellation capability, but I don't think this needs to be part of EcmaScript. If you want to define a `CancelablePromise` subclass which has a `CancelablePromise#cancel()` method, feel free. But I don't think it should be tightly tied to the Promise spec at all. The capability to cancel an operation should be first-class, and able to be passed around independent of the Promise which gives the future result of the operation. I don't think you need to define an unlisten API, either. Just discard the resolve/reject capabilities for the Promise in question. The last time I audited the spec, I convinced myself that this would ensure that all chained promises were also garbage and would be safely collected. (The only pointers to chained promises are held by the resolve/reject capabilities.) --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Exponentiation operator precedence
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
Re: Exponentiation operator precedence
Is there also perhaps a potential performance/static analysis benefit in having it be syntax, rather than a builtin function? `Math.pow` can be overwritten, and varies per-realm, but `**` can not and does not. On Wed, Aug 26, 2015 at 8:21 PM, 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
