Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
On 15 February 2014 21:06, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Feb 15, 2014, at 11:47 AM, Brendan Eich wrote: C. Scott Ananian wrote: On Feb 15, 2014 9:13 AM, Brendan Eich bren...@mozilla.com mailto:bren...@mozilla.com wrote: Aside: ECMASpeak is neither accurate (we don't work for Ecma, it's JS not ES :-P), nor euphonious. I'm learning all sorts of things! I guess there are two names here; what's your preferred phrase for the language used to write algorithms in the ES6 spec (JS6?), and, if it differs, the language used by members of the TC39 committee among themselves when describing language primitives in a very precise way? When I'm in a bad mood, I call it VisualCobol. It's painfully low-level and verbose, yet hard to verify. Let's hope that the JSCert work will help, and Allen has been common'ing subroutines. Whatever we call it, the spec language ain't great. But remember, prior to ES5, it was closer to Cobolish machine language. No structured control, goto's targeting numeric step numbers, intermediate results referenced by step number (sorta SSA with numeric ids), etc. There has never been a complete redo, just incremental improvements and refactorings. But we've definitely advanced from the early 1950s to the late 1970s. Well, Algol-60 already was more structured a language than our spec-speak. Let alone how far the Algol-68 spec was ahead of us. :) /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: On Feb 14, 2014, at 11:38 AM, Jeremy Martin wrote: On further reflection, #3 does feel like trying to rewrite the past. For better or worse, non-strict mode allows declarations to persist past the eval(). And while strict mode provides a license-to-kill on behavior like that, I don't really see strong justification for that kind of surprise factor for let in non-strict mode. If you're not using strict mode AND you're using eval(), the damage is arguably already done (or at least the danger already exists). Changing the behavior of let in this case feels like removing an arbitrary* foot-gun when we're already in the armory, so to speak. * Granted it's not completely arbitrary, since `let` is new whereas `var` is not, but hopefully you get my point. Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. /Andreas ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
On Mon, Feb 17, 2014 at 7:08 AM, Claude Pache claude.pa...@gmail.com wrote: Just a last note. Beyond the philosophical aspect whether arraylikes of negative length make any sense at all, there is a strong technical issue you have probably overlooked: For array methods in general, and for the optional argument of `Array.prototype.copyWithin` in particular (see step 14 of the algorithm), a negative index is not understood as an absolute position, but rather as a position relative to the end of the array. For instance, for an array (or arraylike) of length `n`, if `-3` is passed, it indicates position `n-3`. In your case, it is certainly not the semantics you want. (In fact, everything will happily coerce to `0` at the end of the journey, but it's just happenstance.) I have not overlooked it. The fact that negative `end` is significant is exactly the reason why using `ToLength` on it seems wrong. Even thought `end` defaults to `this.length`, it should still be normalized with `ToInteger` since negative values are semantically valid. But as you point out, I don't think there's any actual behavior change, since everything washes out to `0` at the end. It's just a matter of writing a clearer more consistent spec. --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
C. Scott Ananian wrote: But as you point out, I don't think there's any actual behavior change, since everything washes out to `0` at the end. It's just a matter of writing a clearer more consistent spec. Yet in that light you still have a point, I think. Allen? /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
Andreas Rossberg wrote: On 15 February 2014 20:47, Brendan Eichbren...@mozilla.com wrote: Using -Speak as a stem conjures Orwell. Not good. Ah, relax. Gilad Bracha even named his own language Newspeak. Yeah, but no ECMA -- the double-whammy. Self-mockery is good. I pay my dues (see wat played with commentary at Fluent 2012 and narrated with tech details at Strange Loop 2012). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Another switch
-Messaggio originale-
From: Brendan Eich
Sent: Wednesday, February 12, 2014 2:00 AM
To: Nathan Wall
Cc: Giacomo Cau ; es-discuss@mozilla.org
Subject: Re: Another switch
Definitely good to see new languages being designed and implemented.
JS is not going to break compatibility on the old fall-through behavior
of switch, inherited from Java from C++ from C. All the C-like languages
copy this flaw, because to do otherwise with the same keyword would be
worse (confused users cross-training and -coding among languages would
want our scalps), and IMHO using novel reserved words would be hardly
better.
/be
Nathan Wall mailto:nathan.w...@live.com
February 11, 2014 at 3:21 PM
Hi Giacomo,
Not sure whether this will be of interest to you, but I have been
working on a JS-derived language called Proto (still highly
experimental) which has a switch statement that works exactly as you
described:
https://github.com/Nathan-Wall/proto/blob/master/docs/control/switch.md
Perhaps you will at least find it interesting. :)
Nathan
yes, so great it would be a pleasure to contribute :)
the proposal doesn't want, by no means, to break the compability with the
present syntax and/or semantics of the switch.
At most, should be considered as an extension of current syntax with a
consequential new semantics.
the swith, as it is known, should anyhow be written as
switch (...) {
case ...: ...; break;
case ...: ...; break;
case ...: ...;
case ...: ...; break;
otherwise: ...
}
but, it could be handy to write the same thing with a slightly different syntax:
switch (...) break {
case ...: ...;
case ...: ...;
case ...: ...; continue;
case ...: ...;
otherwise: ...
}
Some break less, no new keyword, no incompatibility with past.
Who shall use it, will know from the start that here, the continue will not
lead him at the beginning of the first for or while that englobe the switch,
but only at the following case.
Then, willingly, we could also think that normal switch be desugared in
switch (...) continue {
case ...: ...; break;
case ...: ...; break;
case ...: ...;
case ...: ...; break;
otherwise: ...
}
with break and continue (except that between ')' and '{' ) that, obviously,
continue as before.
This isn't a must, it's just for my pleasure in finding regularity.
At last, if we were to look for the burden of a new keyword, even better
select (...) {
case ...: ...;
case ...: ...;
case ...: ...; continue;
case ...: ...;
otherwise: ...
}
but I realize this could be a break point of the existing code and, onestly
speaking, it is beyond my ability to evaluate.
Anyhow, thanks for your attention.
bye
Giacomo Cau
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ 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: Changing behavior of Array#copyWithin when used on array-like with negative length
On 2/14/2014 11:40 PM, C. Scott Ananian wrote: On Fri, Feb 14, 2014 at 11:50 AM, André Bargull andre.barg...@udo.edu wrote: I think Scott is requesting this change: https://gist.github.com/anba/6c75c34c72d4ffaa8de7 Yes, although my proposed diff (in the linked bug) was the shorter, 12. If end is undefined, let relativeEnd be ToInteger(lenVal); else let relativeEnd be ToInteger(end). Same effect, though. It's not the same effect, because `lenVal` could be an object with valueOf/toString/@toPrimitive side-effects. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
On Feb 17, 2014, at 12:25 PM, Brendan Eich wrote: C. Scott Ananian wrote: But as you point out, I don't think there's any actual behavior change, since everything washes out to `0` at the end. It's just a matter of writing a clearer more consistent spec. Yet in that light you still have a point, I think. Allen? The ticket is still open, but it really is a style issue and if a change is made here consistency probably requires changes to other methods as well. Right now I have bigger fish to finish frying but at some point I'll consider it. Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
Are recordings available? --scott On Feb 17, 2014 10:26 AM, Brendan Eich bren...@mozilla.com wrote: Andreas Rossberg wrote: On 15 February 2014 20:47, Brendan Eichbren...@mozilla.com wrote: Using -Speak as a stem conjures Orwell. Not good. Ah, relax. Gilad Bracha even named his own language Newspeak. Yeah, but no ECMA -- the double-whammy. Self-mockery is good. I pay my dues (see wat played with commentary at Fluent 2012 and narrated with tech details at Strange Loop 2012). /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Maps with object keys
I'm trying to work with ES6 Map objects and I ran into an interesting
problem.
I want to index/group based on several key values. Let's say my original
data is something like:
```js
[{x:3,y:5,z:3},{x:3,y:4,z:4},{x:3,y:4,z:7},{x:3,y:1,z:1},{x:3,y:5,z:4}]
```
I want to group it based on the x and y property values, so I want the
result to look something like:
```js
{x:3,y:5} == {x:3,y:5,z:3},{x:3,y:5,z:4}
{x:3,y:4} == {x:3,y:4,z:4},{x:3,y:4,z:7}
{x:3,y:1} == {x:3,y:1,z:1}
```
However, as the docs and draft say maps detect existence (
`Map.prototype.has ( key )`) for object the same way `===` works for
objects (specified in `SameValueZero(x, y)`).
I really don't see how to solve this other than implementing my own form of
hashing for these specific objects and 'rolling my own' logic here (instead
of working directly with `Map`s).
For comparison - in Python for example I'd use a dictionary with tuple keys.
So I'm wondering, what's the point of being able to use object keys in
`Map` objects if the equality check performed is reference equality?
I feel like I'm either missing something obvious here or we have a
usability issue on our hands.
Benjamin
(Also asked in SO
http://stackoverflow.com/questions/21838436/map-using-tuples-or-objects )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ 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 -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Changing behavior of Array#copyWithin when used on array-like with negative length
It's not the same effect, because `lenVal` could be an object with valueOf/toString/@toPrimitive side-effects. Point taken. (Although I'm fine with invoking the side effects twice if you're using `this.length` as a default value, since that would be 'unsurprising' if you are looking at the method signature.) Allen: I can volunteer to offload some of the work of auditing for similar cases with default arguments. From a quick read-through, only `Array#fill` seems to have the same issue. `Array#lastIndexOf` is written in the ES5 style, where we look at `arguments.length` instead of using default parameters in the signature. But it does use `ToLength(this.length) - 1` as a default value; I think that could be changed to `ToInteger(this.length) - 1` for consistency without affecting actual behavior. The `copyWithin`, `fill`, and `lastIndexOf`, `subarray` methods of %TypedArray%.prototype are spec'ed with default arguments equal to `this.length`, but there's no way `length` can be negative there, I think (offtopic: ...although I'd really be much happier if the generic Array methods could be written to special-case %TypedArray% in the proper way so that we could observe DRY instead of cloning most of the algorithm descriptions). --scott ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maps with object keys
I understand the capability of python, but that is done through
comprehensions that do not relate to the mapping of key to value.
In ES6 the syntax comes out to:
```
let tuple = {x:3,y:5}
[for (value of map.entries()) if
(Object.keys(tuple).every((tupleKey)=tuple[tupleKey] == value[tupleKey]))
value]
```
A quick comparator function for tuple like objects would be more clear than
comprehension that does not relate to the mapping of key to value. Notice
how the keys of `map` are never used in the comprehension.
On Mon, Feb 17, 2014 at 3:35 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Hi, when you reply please reply to the list (that is, include esdiscuss in
the list of recipients) - otherwise I'm the only one who can read your mail.
As for your question, You might want to look into how maps (or
dictionaries) work in languages like Python where you can have a dictionary
with tuple keys for example which would let me index on `(x,y)` values.
This is of course a very 'simplified' example of what I'm actually doing
(statistical learning).
On Mon, Feb 17, 2014 at 11:31 PM, Bradley Meck bradley.m...@gmail.comwrote:
What you are describing is a Set/Array of data that runs a filter at
runtime. Could you go into some detail on why a filter on sets/arrays does
not make sense for your use case? I am unsure what the original mapping of
key (during .set(key, value)) to value would represent if keys are treated
as many-many filters rather than 1-1 relationships for Maps in ES6.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Maps with object keys
My issue here is that I want to index on complex values. I was under the
impression ES6 maps solve amongst others the problem that with objects -
keys are only strings.
I want to index on 2 (or 100) properties - in this example the x and y
values. I don't want to iterate the whole collection and all the keys every
time I check for existence - that's very inefficient.
Moreover, I don't want to write a for loop over the entries every time I
check for existence - if I wanted that I'd just use an array. Also note,
we're talking about the _keys_ of the map and _not_ the values.
BTW in Python (which I reiterate is just an example) it's done via a hash
function (
https://github.com/python-git/python/blob/master/Objects/tupleobject.c#L290)
that's not the issue though.
On Mon, Feb 17, 2014 at 11:43 PM, Bradley Meck bradley.m...@gmail.comwrote:
I understand the capability of python, but that is done through
comprehensions that do not relate to the mapping of key to value.
In ES6 the syntax comes out to:
```
let tuple = {x:3,y:5}
[for (value of map.entries()) if
(Object.keys(tuple).every((tupleKey)=tuple[tupleKey] == value[tupleKey]))
value]
```
A quick comparator function for tuple like objects would be more clear
than comprehension that does not relate to the mapping of key to value.
Notice how the keys of `map` are never used in the comprehension.
On Mon, Feb 17, 2014 at 3:35 PM, Benjamin (Inglor) Gruenbaum
ing...@gmail.com wrote:
Hi, when you reply please reply to the list (that is, include esdiscuss
in the list of recipients) - otherwise I'm the only one who can read your
mail.
As for your question, You might want to look into how maps (or
dictionaries) work in languages like Python where you can have a dictionary
with tuple keys for example which would let me index on `(x,y)` values.
This is of course a very 'simplified' example of what I'm actually doing
(statistical learning).
On Mon, Feb 17, 2014 at 11:31 PM, Bradley Meck bradley.m...@gmail.comwrote:
What you are describing is a Set/Array of data that runs a filter at
runtime. Could you go into some detail on why a filter on sets/arrays does
not make sense for your use case? I am unsure what the original mapping of
key (during .set(key, value)) to value would represent if keys are treated
as many-many filters rather than 1-1 relationships for Maps in ES6.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation A better statement of the question would be can we agree that lexical bindings created by eval are always non-deletable binding. Where or not is throws which the various modes is already determined by the existing spec. for delete based upon whether or not the binding is deletable. Allen On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote: In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ 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 -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
+1. On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation A better statement of the question would be can we agree that lexical bindings created by eval are always non-deletable binding. Where or not is throws which the various modes is already determined by the existing spec. for delete based upon whether or not the binding is deletable. Allen On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote: In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ 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 -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
I'm getting vary. Does that mean that you want to change the semantics since ES5.1? On Mon Feb 17 2014 at 5:12:24 PM, Mark S. Miller erig...@google.com wrote: +1. On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock al...@wirfs-brock.comwrote: See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation A better statement of the question would be can we agree that lexical bindings created by eval are always non-deletable binding. Where or not is throws which the various modes is already determined by the existing spec. for delete based upon whether or not the binding is deletable. Allen On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote: In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.comwrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ 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 -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
No, absolutely not. By lexical, I took Allen to mean the new reliably block-local binding forms: let, const, class On Mon, Feb 17, 2014 at 2:17 PM, Erik Arvidsson erik.arvids...@gmail.comwrote: I'm getting vary. Does that mean that you want to change the semantics since ES5.1? On Mon Feb 17 2014 at 5:12:24 PM, Mark S. Miller erig...@google.com wrote: +1. On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation A better statement of the question would be can we agree that lexical bindings created by eval are always non-deletable binding. Where or not is throws which the various modes is already determined by the existing spec. for delete based upon whether or not the binding is deletable. Allen On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote: In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ 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 -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maps with object keys
It is straightforward to implement a hash function based map as a
subclass of `Map`. Something like:
```js
var HashMap = function() { this._map = new Map(); };
HashMap.set = function(key, value) {
var hash = key.hashCode();
var list = this._map.get(hash);
if (!list) { list = []; this._map.set(hash, list); }
for (var i=0; ilist.length; i++) {
if (list[i].key.equals(key)) {
list[i].value = value;
return;
}
}
list[i].push({key: key, value: value });
};
// etc
```
(For simplicity I used delegation above, rather than a subclass, and I
used ES5 syntax.)
Note that the above implementation makes a number of assumptions which
the ES6 designers decided were *not* appropriate to hardcode into the
language:
1. All object used as keys must implement `hashCode` and `equals` with
appropriate semantics.
2. Hash code collisions cause the map to revert to linear search.
(Alternatively you could implement a different variant of hashtable
chaining.)
ES6 includes only the basic `Map` primitive, on top of which you can
build the infinite variety of different `Map` variants.
I expect that we will begin to see helper libraries built on top of
ES6 primitives. As an example, I wrote `prfun` to provide
Promise-related helpers on top of the (similarly bare-bones) ES6
`Promise`. Presumably we'll eventually see some library with a name
like `javamap` to provide java-style `hashCode`/`equals` maps on top
of ES6 `Map` for those who want that.
--scott
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Maps with object keys
Le 17/02/2014 22:55, Benjamin (Inglor) Gruenbaum a écrit : My issue here is that I want to index on complex values. I was under the impression ES6 maps solve amongst others the problem that with objects - keys are only strings. With maps, all native types (string, number, boolean, undefined, null, object) can be keys. For complex values, funnel your values down to one of these (by hashing or serializing or whatever fits your need). It's easy enough to write and enough use case specific to justify not being part of the language. David ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Status of Array.prototype.contains
Hi, In the latest draft, I see String.prototype.contains, but no Array.prototype.contains I see something about a no-brainer here https://mail.mozilla.org/pipermail/es-discuss/2011-December/019108.html I haven't found a bug on bugs.ecmascript or a mention in the meeting notes. Or was it superseded by .find? ... or is introducing it risking to break half of the web? Might be useful to put an end to the ~arr.indexOf tricks [1] David [1] https://mxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/event/core.js#45 ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: eval of let, etc. Was: Re: restrictions on let declarations
Right, let/const/class Allen On Feb 17, 2014, at 2:19 PM, Mark Miller wrote: No, absolutely not. By lexical, I took Allen to mean the new reliably block-local binding forms: let, const, class On Mon, Feb 17, 2014 at 2:17 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: I'm getting vary. Does that mean that you want to change the semantics since ES5.1? On Mon Feb 17 2014 at 5:12:24 PM, Mark S. Miller erig...@google.com wrote: +1. On Mon, Feb 17, 2014 at 2:06 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: See http://people.mozilla.org/~jorendorff/es6-draft.html#sec-delete-operator-runtime-semantics-evaluation A better statement of the question would be can we agree that lexical bindings created by eval are always non-deletable binding. Where or not is throws which the various modes is already determined by the existing spec. for delete based upon whether or not the binding is deletable. Allen On Feb 17, 2014, at 1:16 PM, Mark S. Miller wrote: In this context, there are two things you might mean by throws: a) That this delete is an early error within the evaled program, and therefore throws before any of the code in the evaled program executes. b) That the delete is a dynamic error that happens when the delete executes, and therefore that the evaled code prior to the delete has executed before the error is thrown. -1 on #b. Assuming you mean #a, between #a and silence, I'm torn. Here are pros and cons: pro #a: The program is wrong. Silence fails to bring it to anyone's attention, making the mistake less likely to be fixed. And making it more likely the program's execution deviates from author's intent. con #a: Silence on sloppy wrong programs are least surprise, and is arguably the most vivid different between sloppy and strict. I doubt there's any sensible choices other than #a and silence. On Mon, Feb 17, 2014 at 12:52 PM, Allen Wirfs-Brock al...@wirfs-brock.com wrote: So, #3 appears to be the winner. Given that, can we also agree that this is throws (or at least that the delete does nothing): eval (let x=5; delete x;); (bug https://bugs.ecmascript.org/show_bug.cgi?id= ) Allen On Feb 17, 2014, at 8:02 AM, Erik Arvidsson wrote: I'm also fine with 3. On Mon Feb 17 2014 at 10:39:47 AM, Jeremy Martin jmar...@gmail.com wrote: Happy to concede to #3 on my end. Just wanted to be clear that it seems to be optimizing for future happiness vs. least surprising behavior (which isn't a bad thing). On Mon, Feb 17, 2014 at 10:26 AM, Jorge Chamorro jo...@jorgechamorro.com wrote: On 17/02/2014, at 13:42, Andreas Rossberg wrote: On 15 February 2014 06:10, Brendan Eich bren...@mozilla.com wrote: Allen Wirfs-Brock wrote: Another consideration in the back of my mind is that there may be useful to implementors to knowing that let/const/class declaration are never dynamically added to a non-global environment. +lots, this should be front of mind. In a block, we want the bindings local to that block to be statically analyzable. We want no non-local mode effects. So, #3 still wins. Strongly seconded. And even thirded. -- ( Jorge )(); ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Jeremy Martin 661.312.3853 http://devsmash.com @jmar777 ___ 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 -- Cheers, --MarkM -- Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Text by me above is hereby placed in the public domain Cheers, --MarkM ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: `String.prototype.symbolAt()` (improved `String.prototype.charAt()`)
C. Scott Ananian wrote: Are recordings available? http://www.infoq.com/presentations/State-JavaScript starting at 1:50 Youtube has more. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maps with object keys
On Mon, Feb 17, 2014 at 3:09 PM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: I'm trying to work with ES6 Map objects and I ran into an interesting problem. Yes! Well done. We've noticed this too, and considered (a) allowing objects to provide their own hash and equals operations, as in Java and Python; (b) allowing the Map user to specify hash and equals operations for the Map at construction time. These were rejected partly because both ideas would make Map behavior observably nondeterministic, or else overspecify. Also because object hash codes would be exposed to users, and ensuring that those do not leak any information about object addresses would likely make them slow. The solution that prevailed is (c) introduce value types in ES7. With value types, you'll be able to declare an aggregate value type, much like a Python namedtuple, to use as your Map key. Values of that type can be compared for equality with ===, like Python tuples, and Map will work accordingly. Until value types are spec'd and implemented, the other workarounds already mentioned in this thread will have to do, I'm afraid. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Maps with object keys
Thanks, I was starting to feel like I wasn't explaining my issue very well given the other replies. I'm glad we agree this is not something user-code should have to shim for language level collections. I'm working on several projects that perform statistical analysis and I wanted to stick to JavaScript, this makes it really hard to do so. It effectively renders `Map`s useless for me exept for readability purposes. Also, thanks for the straight up 'this is still a problem now' - it probably saved me a considerable amount of time. Value types do sound like a better solution than throwing `equals` and `hash` on every object, it is conceptually similar to the solution I've got so far (using a flyweight to enforce uniqueness and generate 'value objects'). (Of course the current solution has memory issues which I need to be careful about - but I hope I'll manage) I do think there might be a problem with value types (or rather, value objects) for key though - if I followed correctly, value types do not allow you to specify `===` and `!==` yourself, they are a recursive structural equality test which limits your ability to ignore properties you do not care about. For example, getting points that are unique points on the R2 (x,y plane) by throwing R3 points (x,y,z) into a set with x,y equality and then extracting them. I'm not sure if this was discussed or if it's a big enough issue but I think it's worth talking about. Thanks, Benjamin On Tue, Feb 18, 2014 at 4:50 AM, Jason Orendorff jason.orendo...@gmail.comwrote: On Mon, Feb 17, 2014 at 3:09 PM, Benjamin (Inglor) Gruenbaum ing...@gmail.com wrote: I'm trying to work with ES6 Map objects and I ran into an interesting problem. Yes! Well done. We've noticed this too, and considered (a) allowing objects to provide their own hash and equals operations, as in Java and Python; (b) allowing the Map user to specify hash and equals operations for the Map at construction time. These were rejected partly because both ideas would make Map behavior observably nondeterministic, or else overspecify. Also because object hash codes would be exposed to users, and ensuring that those do not leak any information about object addresses would likely make them slow. The solution that prevailed is (c) introduce value types in ES7. With value types, you'll be able to declare an aggregate value type, much like a Python namedtuple, to use as your Map key. Values of that type can be compared for equality with ===, like Python tuples, and Map will work accordingly. Until value types are spec'd and implemented, the other workarounds already mentioned in this thread will have to do, I'm afraid. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
