To me this sounds as a good idea, I was actually under the impression that
it would be under Math until I saw the first ES6 draft featuring clz.
Having it under Math not only seems more consistent to me, but also lets
you do nice things like `numbers.map(Math.clz)`.
Cheers,
Jussi
On Wed, Jan
On Wed, Jan 15, 2014 at 1:26 PM, Allen Wirfs-Brock
al...@wirfs-brock.com wrote:
So we discussed all that when we made that decision. I understand that you
disagree but is there any new data that should cause us to reopen an issue
that was already discussed and decided at a TC39 meeting?
What's the method for determining whether we run the multimethod dispatch
algorithm versus the ES6 abstract equality algorithm?
One or both operands value objects.
Gotcha. One more, I think.
int64(0) === 0L
I assume that int64 is not defined as a composition of primitives or value
On Jan 16, 2014, at 7:38 AM, Kevin Smith zenpars...@gmail.com wrote:
What's the method for determining whether we run the multimethod dispatch
algorithm versus the ES6 abstract equality algorithm?
One or both operands value objects.
Gotcha. One more, I think.
int64(0) === 0L
At the risk of putting too many nails in the board...
The rationale seems to propose that (0).clz() === 32, but the
hypothetical uint64(0).clz() would return 64. That seems like a bad
idea though. It's weird for two zero values to get such different
behavior from the same method. It's weird for
[oops - reply all this time]
Value objects have value, not reference, semantics. JS has string number
boolean already (note lowercase names). With value objects, users and the
host env can define others.
Makes sense, but I thought the user could not define semantics for ===:
it just means
Kevin Smith mailto:zenpars...@gmail.com
January 16, 2014 8:26 AM
[oops - reply all this time]
Value objects have value, not reference, semantics. JS has string
number boolean already (note lowercase names). With value objects,
users and the host env can define others.
Makes sense,
Kevin Smith wrote:
It's opaque. If you self-hosted using a Uint32Array of length
two (e.g.), you'd have to declare that as the per-instance
state for the value class. I didn't show syntax for that --
working on it still.
And if you for some reason used
Brendan Eich wrote:
It would be better to repair == by allowing developers to opt string
and boolean (note lowercase) into B
And number too.
Will try to get all this drafted, just not today.
/be
___
es-discuss mailing list
es-discuss@mozilla.org
On Thu, Jan 16, 2014 at 10:07 AM, Mark S. Miller erig...@google.com wrote:
On Thu, Jan 16, 2014 at 8:40 AM, Jason Orendorff
jason.orendo...@gmail.com wrote:
At the risk of putting too many nails in the board...
The rationale seems to propose that (0).clz() === 32, but the
hypothetical
On 2014/01/16, at 17:40, Jason Orendorff jason.orendo...@gmail.com wrote:
At the risk of putting too many nails in the board...
The rationale seems to propose that (0).clz() === 32, but the
hypothetical uint64(0).clz() would return 64. That seems like a bad
idea though. It's weird for two
On Thu, Jan 16, 2014 at 12:09 PM, Joshua Bell jsb...@google.com wrote:
On Thu, Jan 16, 2014 at 10:07 AM, Mark S. Miller erig...@google.comwrote:
On Thu, Jan 16, 2014 at 8:40 AM, Jason Orendorff
jason.orendo...@gmail.com wrote:
At the risk of putting too many nails in the board...
The
On Thu, Jan 16, 2014 at 1:12 PM, Jens Nockert j...@nockert.se wrote:
On 2014/01/16, at 17:40, Jason Orendorff jason.orendo...@gmail.com
wrote:
At the risk of putting too many nails in the board...
The rationale seems to propose that (0).clz() === 32, but the
hypothetical
On Thu, Jan 16, 2014 at 1:12 PM, Jens Nockert j...@nockert.se wrote:
On 2014/01/16, at 17:40, Jason Orendorff jason.orendo...@gmail.com
wrote:
Or maybe: flip the function around so that it returns the number of
bits in the binary expansion of the value: Math.bitlen(15) === 4. This
is
On Thu, Jan 16, 2014 at 1:58 PM, Brendan Eich bren...@mozilla.com wrote:
Kevin Reid wrote:
FWIW: Common Lisp has rigorously transparent (that is, you cannot observe
the machine word size) bigints and quite a few binary operations defined on
them, so it's where I personally would look for
On Thu, Jan 16, 2014 at 1:56 PM, Mark S. Miller erig...@google.com wrote:
Why is logcount called logcount? As the doc on integer-length makes
clear, it has a strong relation to the log-base-2 of the number. logcount
does not.
Common Lisp calls most *bitwise* functions of integers
Kevin Reid wrote:
On Thu, Jan 16, 2014 at 1:58 PM, Brendan Eich bren...@mozilla.com
mailto:bren...@mozilla.com wrote:
Kevin Reid wrote:
FWIW: Common Lisp has rigorously transparent (that is, you
cannot observe the machine word size) bigints and quite a few
binary
On Thu, Jan 16, 2014 at 3:12 PM, Jens Nockert j...@nockert.se wrote:
On 2014/01/16, at 17:40, Jason Orendorff jason.orendo...@gmail.com wrote:
Or maybe: flip the function around so that it returns the number of
bits in the binary expansion of the value: Math.bitlen(15) === 4. This
is just (32
Jason Orendorff wrote:
What is Math.bitlen(-1) then? Isn’t this just the same problem as before,
except it happens for negative numbers instead of positive?
No opinion.
Not sure it matters. We could return -1 for any negative number, 0 for
0, and 0 for positive integral values.
/be
would -0 return -1 too ? I could not resist asking for this, sorry!
On Thu, Jan 16, 2014 at 7:20 PM, Brendan Eich bren...@mozilla.com wrote:
Jason Orendorff wrote:
What is Math.bitlen(-1) then? Isn’t this just the same problem as
before, except it happens for negative numbers instead of
20 matches
Mail list logo
