Re: Object.is()
On 23 December 2013 03:17, Alex Kocharin a...@kocharin.ru wrote: That's something I never really understood when I was reading ES5 spec, where -0 is a special case, and a sole reason why `x === Number(String(x))` is not true for all numbers. NaN is another special case. IEEE equality is just broken, Why isn't it stringified as -0? How did that happen? Do somebody really check if something is less than zero using - in string representation? Lacking true integers, that would break JavaScript's poor man's emulation of arrays. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.is()
Andreas Rossberg wrote: On 23 December 2013 03:17, Alex Kocharina...@kocharin.ru wrote: That's something I never really understood when I was reading ES5 spec, where -0 is a special case, and a sole reason why `x === Number(String(x))` is not true for all numbers. NaN is another special case. IEEE equality is just broken, ... in your hardware, all of it. Standards from the last days of Disco, like Disco, will never die. Why isn't it stringified as -0? How did that happen? Do somebody really check if something is less than zero using - in string representation? Lacking true integers, that would break JavaScript's poor man's emulation of arrays. C'mon, that's not the reason. Hardly anyone generates -0 as an index and expects it to index a[0] for some array a. Things to complain about! :-P /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: const VS features detection
On 6 January 2014 17:59, Allen Wirfs-Brock al...@wirfs-brock.com wrote:
The major new complication of do-expressions is that they allow for the
occurrence of break/continue/return abrupt completions in contexts such as
for loop heads where they could not perviously occur. However,
do-expressions where still on the table when I did the spec. work for
completion reform so the ES6 draft already deals with these abrupt
completions in those contexts. Even though there is currently no way to
produce them.
I agree that's a complication, which is why I would propose to
disallow them, at least for the time being. Motivation:
- YAGNI -- I have a hard time coming up with a use case that isn't
obfuscated code (even considering generated code).
- They complicate the semantics and implementation -- for example, you
would have to roll back non-empty expression stacks (in a stack
machine implementation).
- They destroy nice equivalences -- in particular, I'd like do {...}
to be equivalent to (() = {...})(), e.g. to minimise refactoring
hazards.
- We can always allow them later, if the need should ever arise.
Dave, I remember you were in favour of allowing these. Do you have
specific use cases in mind?
/Andreas
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Object.is()
On 7 January 2014 15:28, Brendan Eich bren...@mozilla.com wrote: Andreas Rossberg wrote: On 23 December 2013 03:17, Alex Kocharina...@kocharin.ru wrote: That's something I never really understood when I was reading ES5 spec, where -0 is a special case, and a sole reason why `x === Number(String(x))` is not true for all numbers. NaN is another special case. IEEE equality is just broken, ... in your hardware, all of it. Standards from the last days of Disco, like Disco, will never die. Yes. Yet there is no reason why languages keep using it as the generic equality on floats. It could be a separate operator. Especially since comparing floats for equality is disadvised against anyway... Why isn't it stringified as -0? How did that happen? Do somebody really check if something is less than zero using - in string representation? Lacking true integers, that would break JavaScript's poor man's emulation of arrays. C'mon, that's not the reason. Hardly anyone generates -0 as an index and expects it to index a[0] for some array a. Things to complain about! :-P It's not all that difficult to accidentally create a -0 when you do pure integer arithmetic with floats. I'm pretty sure it would be a major pitfall. Wasn't that the reason why we changed Map? /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Object.is()
Andreas Rossberg wrote: Lacking true integers, that would break JavaScript's poor man's emulation of arrays. C'mon, that's not the reason. Hardly anyone generates-0 as an index and expects it to index a[0] for some array a. Things to complain about!:-P It's not all that difficult to accidentally create a-0 when you do pure integer arithmetic with floats. I'm pretty sure it would be a major pitfall. Wasn't that the reason why we changed Map? Maybe, and I'm not thrilled about that change, but Map is new, and different from Array or array-likes anyway (value to value mapping). My point was Array indexing is the least of our concerns. Changing (-0).toString() will probably break tons of code, including numeric form code, even if only showing -0 to users who want 0. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: const VS features detection
Andreas Rossberg wrote:
- YAGNI -- I have a hard time coming up with a use case that isn't
obfuscated code (even considering generated code).
Always a good reason in the abstract, but concrete use cases have
arisen, even in this thread. As you noted just last month (!),
For ES7 I would like to revive the do-expression proposal (hopefully
at the next meeting), so that one can at least approximate the above
with
const ES6_PROXY = do { try { new Proxy({}, {}); true } catch (_) { false } };
Of course, semantically the function is equivalent, and a fine
solution, if a bit verbose.
- They complicate the semantics and implementation -- for example, you
would have to roll back non-empty expression stacks (in a stack
machine implementation).
This is minor in both actual effect (not many naive recursive expression
parse-tree walkers) and implementation hardship (return completion types
all over, respect abrupt ones in expression handlers).
- They destroy nice equivalences -- in particular, I'd like do {...}
to be equivalent to (() = {...})(), e.g. to minimise refactoring
hazards.
What changed your mind from 20-December?
Anyway, JS has statements and expressions, but functions create new
activations with their own scopes. Those create hazards when refactoring
between statements and expressions.
Wanting the equivalence you state here tries to deny the facts of JS and
its full (ahem, perhaps disputed legitimacy) heritage.
- We can always allow them later, if the need should ever arise.
ES7 is later.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: const VS features detection
Sorry, my wording may have been ambiguous. What I meant was
disallowing break/continue/return inside a 'do', not giving up 'do'.
;)
/Andreas
On 7 January 2014 17:10, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
- YAGNI -- I have a hard time coming up with a use case that isn't
obfuscated code (even considering generated code).
Always a good reason in the abstract, but concrete use cases have arisen,
even in this thread. As you noted just last month (!),
For ES7 I would like to revive the do-expression proposal (hopefully
at the next meeting), so that one can at least approximate the above
with
const ES6_PROXY = do { try { new Proxy({}, {}); true } catch (_) { false }
};
Of course, semantically the function is equivalent, and a fine
solution, if a bit verbose.
- They complicate the semantics and implementation -- for example, you
would have to roll back non-empty expression stacks (in a stack
machine implementation).
This is minor in both actual effect (not many naive recursive expression
parse-tree walkers) and implementation hardship (return completion types all
over, respect abrupt ones in expression handlers).
- They destroy nice equivalences -- in particular, I'd like do {...}
to be equivalent to (() = {...})(), e.g. to minimise refactoring
hazards.
What changed your mind from 20-December?
Anyway, JS has statements and expressions, but functions create new
activations with their own scopes. Those create hazards when refactoring
between statements and expressions.
Wanting the equivalence you state here tries to deny the facts of JS and its
full (ahem, perhaps disputed legitimacy) heritage.
- We can always allow them later, if the need should ever arise.
ES7 is later.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: const VS features detection
On 7 January 2014 17:19, Andreas Rossberg rossb...@google.com wrote:
Sorry, my wording may have been ambiguous. What I meant was
disallowing break/continue/return inside a 'do', not giving up 'do'.
;)
And just to be extra-clear: by that I'm only referring to free
occurrences of those, that would refer to the enclosing statement.
Nested ones are fine, of course.
/Andreas
On 7 January 2014 17:10, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
- YAGNI -- I have a hard time coming up with a use case that isn't
obfuscated code (even considering generated code).
Always a good reason in the abstract, but concrete use cases have arisen,
even in this thread. As you noted just last month (!),
For ES7 I would like to revive the do-expression proposal (hopefully
at the next meeting), so that one can at least approximate the above
with
const ES6_PROXY = do { try { new Proxy({}, {}); true } catch (_) { false }
};
Of course, semantically the function is equivalent, and a fine
solution, if a bit verbose.
- They complicate the semantics and implementation -- for example, you
would have to roll back non-empty expression stacks (in a stack
machine implementation).
This is minor in both actual effect (not many naive recursive expression
parse-tree walkers) and implementation hardship (return completion types all
over, respect abrupt ones in expression handlers).
- They destroy nice equivalences -- in particular, I'd like do {...}
to be equivalent to (() = {...})(), e.g. to minimise refactoring
hazards.
What changed your mind from 20-December?
Anyway, JS has statements and expressions, but functions create new
activations with their own scopes. Those create hazards when refactoring
between statements and expressions.
Wanting the equivalence you state here tries to deny the facts of JS and its
full (ahem, perhaps disputed legitimacy) heritage.
- We can always allow them later, if the need should ever arise.
ES7 is later.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: const VS features detection
On Jan 7, 2014, at 8:22 AM, Andreas Rossberg wrote:
On 7 January 2014 17:19, Andreas Rossberg rossb...@google.com wrote:
Sorry, my wording may have been ambiguous. What I meant was
disallowing break/continue/return inside a 'do', not giving up 'do'.
;)
And just to be extra-clear: by that I'm only referring to free
occurrences of those, that would refer to the enclosing statement.
Nested ones are fine, of course.
Unless we can identify real implementation issues, the semantics of
do { }
should simply be those of a blocks. JS programmer shouldn't have to learn
which subset of statement are invalid in a do expression block. In particular,
I see no reason why a JS programmer should be able to refactor any valid
BlockStatement in to an equivalent ExpressionStatement simply by putting a 'do'
in front of the leading '{'
The meaning of things like:
function (x) {
for (let i of x.state!==special? x : do {return bar(x)})
foo(i)
}
is clear and also easy enough to specify. Unless there are some non-obvious
implementation issues, I don't see why we would want to disallow such things.
The only place where the possible semantics isn't totally obvious is things
like:
for (x of z ? q : do {break}) ...
or
for (x of do { if (z) q; else continue}) ...
The semantics in the ES6 draft for an unlabeled break or continue completion in
the head of a for statement threats both of these as terminating the for
statement and continuing with the statement following the for.
Allen
/Andreas
On 7 January 2014 17:10, Brendan Eich bren...@mozilla.com wrote:
Andreas Rossberg wrote:
- YAGNI -- I have a hard time coming up with a use case that isn't
obfuscated code (even considering generated code).
Always a good reason in the abstract, but concrete use cases have arisen,
even in this thread. As you noted just last month (!),
For ES7 I would like to revive the do-expression proposal (hopefully
at the next meeting), so that one can at least approximate the above
with
const ES6_PROXY = do { try { new Proxy({}, {}); true } catch (_) { false }
};
Of course, semantically the function is equivalent, and a fine
solution, if a bit verbose.
- They complicate the semantics and implementation -- for example, you
would have to roll back non-empty expression stacks (in a stack
machine implementation).
This is minor in both actual effect (not many naive recursive expression
parse-tree walkers) and implementation hardship (return completion types all
over, respect abrupt ones in expression handlers).
- They destroy nice equivalences -- in particular, I'd like do {...}
to be equivalent to (() = {...})(), e.g. to minimise refactoring
hazards.
What changed your mind from 20-December?
Anyway, JS has statements and expressions, but functions create new
activations with their own scopes. Those create hazards when refactoring
between statements and expressions.
Wanting the equivalence you state here tries to deny the facts of JS and its
full (ahem, perhaps disputed legitimacy) heritage.
- We can always allow them later, if the need should ever arise.
ES7 is later.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
