2013-12-22 Thread Olov Lassus
2013/12/23 Brendan Eich

 You are reasoning from general to particular, but without any reason to
 focus on the particular of redefining a non-writable property from -0 to +0
 or vice versa. There is no use-case there there! I bet Mark would find
 that a subtle security problem.

On the topic of +0, -0 and use cases... Is it still intended that Map and
Set will distinguish between these two values? I'm not sure what the use
case would be but I fear the consequences. Further elaborated in

es-discuss mailing list


2013-12-22 Thread Olov Lassus
2013/12/23 Mark S. Miller

 No, Map and Set will equate -0 and +0.


Filed a bug on v8:
es-discuss mailing list

Re: if-scoped let

2013-12-04 Thread Olov Lassus
2013/11/29 Nick Krempel

 Couldn't find anything on this in the archives, but is there a proposal

 if (let var = expr) {
   // var in scope
 (const should also be OK in place of let, at least for if and

Thanks for taking this to the list. I was meaning to do it after a
discussion with Allen at Front-Trends earlier this year but never got
around to it, partly because Allen (correctly) suggested that it was almost
certainly too late for ES6. I back this also.

Another perspective of why this is a great feature: My ES6 programming is
const-first, meaning I only use let for bindings that change and const for
everything else. In practice over 90% of all my variables are const which
is great because the let's that are in there really stand out. The
unfortunate consequence of not being able to declare a variable inside the
if-condition (for example) is that it forces const's to let's.

I wanted to do

if (const val = compute(something)) {
// ...

but I had to do

let val;
if (val = compute(something)) {
// ...

which is unfortunate not only because val leaks to the outer scope but also
because let suggest that the binding mutates (which it technically does,
but practically doesn't).

es-discuss mailing list

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Olov Lassus
2013/10/30 Vyacheslav Egorov

 5. A one shot property Math.H is created that returns ch' on the first
 access and deletes itself.

Alternative step 5: Math.H is assigned ch'.

Rationale being faster polyfilled execution, in combination with a lack of
imagination from my side to come up with a use case where any code would be
interested in knowing (at run-time) whether Math.H exists or not (i.e.
whether it has already been read). Does such a use case exist?

If all of JSC, Chakra, V8 reliably optimizes away most overhead of a
polyfilled Math.H getter then perhaps this does not matter.

es-discuss mailing list

Re: proposal for efficient 64-bit arithmetic without value objects

2013-10-30 Thread Olov Lassus
2013/10/30 Vyacheslav Egorov

  Rationale being faster polyfilled execution

 The main reason for H being one shot is to allow optimizing compiler
 *elide* updating it in most cases to eliminate memory traffic.

Aaah. Thanks for pointing this out - I thought only of the polyfill
performance so I neglected this key aspect of your proposal.

 After thinking about it a bit I propose the following alternative step 5:

 Math.H is from the very beggining a non-configurable non-writable
 accessor property with a getter that returns hidden inner value and
 always zeros inner value.

+1 (for now) :)

es-discuss mailing list

Re: B.3.1 The __proto__ pseudo property

2013-04-21 Thread Olov Lassus
2013/4/21 Allen Wirfs-Brock
  Also note that JSON.parse('{__proto__: null}') does not create an object 
 whose [[Protoype]] is null because JSON.parse uses [[DefineOwnProperty]] to 
 create all its properties so this will just result in an own property whose 
 value is null.

Side-tracking the discussion but perhaps someone will find it interesting:
That varies with JS implementations. v8 as of Chrome and Node stable
sets [[Prototype]] so you can cause all kinds of crazy things
happening by doing a JSON.parse('{__proto__: null}'),
JSON.parse('{__proto__: []}') or why not a JSON.parse('{__proto__:
{sessionid: cantbedeleted}}'). v8 bleeding edge and Chrome Canary
has fixed this. for
more info.

es-discuss mailing list

Re: Number.isNaN

2012-12-18 Thread Olov Lassus
2012/12/14 Allen Wirfs-Brock

 BTW, I think there are probably other related issues that need to be
 discussed/resolved at that level.  For example, is SameValue really want we
 want for Map/Set equivalence (the -0 different from +0 issue), did we agree
 to parameterize the equivalance operator for Map/Set?,  and the question
 about the need for Number.isNaN if we have available.

I'm happy to read that the unintentional dual zeroes issue is being
considered by committee members. My attempt to raise this issue two weeks
back (,-0) and its data structures implications
didn't generate any public responses, however multiple people responded
privately about it. Thanks!

es-discuss mailing list,-0) and its data structures implications

2012-12-03 Thread Olov Lassus
I've been thinking about our IEEE-inherited positive and negative zero and the 
proposed ES6 and new collections semantics. I haven't followed any 
discussions about this so I'm basing my understanding purely on the Harmony 
wiki and toying around with the preliminary support in v8. Bear with me if I'm 
misunderstanding badly or raising a topic that has been discussed at length 
already. From what I can understand, it has been decided that there need to be 
a convenient way to distinguish between +0 and -0 but also that this new form 
of sameness ( should be used in the new collections, such as Maps and 
Sets. I don't mind having a convenient way of testing which zero but I'm a bit 
concerned that the added expressiveness of being able to store the two 
different zeroes in the same Set/Map (seems like a rare use case) is hugely 
dwarfed by the issues it may cause in the common case.

var s = new Set();

The set now contains two items. That may seem reasonable from the code above 
since after all I explicitly added those two items. Then consider the cases 
where the (integer) keys are calculated at runtime. With 
integers-implemented-with-floating-point it's quite easy to end up with a 
negative zero in ways that wouldn't happen in a language with 
integers-implemented-with-integers. Such as -100 * 0. In an IEEE world (so in 
JS) that's -0. I'm guessing most JS programmers don't know that, for good 

To further add to the confusion, now consider that for i = 0 and j = -0: i = j 
 i = j  i === j but s.has(i) !== s.has(j). WAT?

There are plenty of ways to end up with negative zeroes unexpectedly. Here's an 
abs that I guess most programmers would think of as correct (assuming integer 
usage) but it isn't because unlike Math.abs we're not using fabs() and we 
didn't add the extra code to handle negative zero. That has pretty dramatic 
consequences considering and new data structures.

// abs(-0) is broken and we used to get away with it
function abs(x) { return x  0 ? -x : x; }
var m = new Map();
[-1, -0, 0, 1].forEach(function(v) { m.set(abs(v), v); });
// Oops. m has three, not two, items

So how are others doing? In Python, Ruby and Lua, a dict/hash/table doesn't 
distinguish between +0 and -0 keys. Same goes for a std::mapdouble, 
std::string in C++. A Java HashMapDouble, String does, because of 
Double.equals semantics. But even so, the Java user would rather use a 
HashMapInteger, String when using integer keys, in which there is only one 
zero. JS users don't have that choice, will use Maps/Sets with integer keys far 
more often than with floating point keys, yet I feel that we're optimizing for 
a corner case of the latter.

I'm thinking that this is a pretty high tax to put on JS users. Is it worth it?


es-discuss mailing list