Re: Syntax sugar for partial application
On Thu, Apr 9, 2015 at 4:04 PM, liorean lior...@gmail.com wrote: Do we really need it? Your «foo(1, ?, 2);» is equivalent to «a=foo(1,a,2)». Your «foo(?, 1, ???);» is equivalent to «(a,...b)=foo(a,1,...b)». Your «foo(1, ???, 2);» is equivalent to «(...a)=foo(...[1,...a,2])». Not exactly. Using the placeholder syntax, `this` remains context dependent, whereas with your examples you get `null` as `this`. This might not seem like such a big deal until you consider it in combination with the proposed bind syntax [1]. Also in your examples, redefining `foo` will lead to different results. The placeholder syntax has a lot more room for optimization in the JIT compiler (the partially applied result is guaranteed to have no side effects for example, so the compiler can create a version of the original function where it can inline the specified arguments; less moving parts, easier to optimize). [1] http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator Also, the ? token is already taken by the ternary conditional operator. Do we really want to overload it here for a nullary operator/special form, when we have as low overhead syntax as we already do in fat arrows for doing the exact same thing? -- David liorean Andersson ___ 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: loop unrolling and completion values in ES6
On 2015-04-08 16:59, Allen Wirfs-Brock al...@wirfs-brock.com writes:
Well, they do for normal loop completions (according to the spec.) but not for
breaks. I this the latter is a bug. In particular, I think it is pretty
obvious that:
eval(“ {0; while (true) {1; break}; 2}”)
should evaluate to 1
It is a little less obvious for:
eval(“{0; L: while (true) {1; while (true) {2; break L; 3}; 4}; 5}”)
but, I think that consistency with the first case requires this to
evaluate to 2.
I think these cases are already fine (modulo the final expression
statement, ; 2 and ; 5, which should not be there as Brendan said):
since the body of the while is a block, the return value is patched as
expected in the block evaluation semantics (step 5):
1. Let sl be the result of evaluating StatementList.
2. ReturnIfAbrupt(sl).
3. Let s be the result of evaluating StatementListItem.
4. If s.[[type]] is throw, return Completion(s).
5. If s.[[value]] is empty, let V = sl.[[value]], otherwise let V = s.[[value]].
6. Return Completion{[[type]]: s.[[type]], [[value]]: V, [[target]]:
s.[[target]]}.
The problem happens when the first statement of the body of the while
loop is a break: in that case the value from the previous iteration is
not carried over.
So, it’s arguably a bug that the ES6 spec. hasn’t changed in that regard
relative to ES3/5.
I looked deeper into the differences between ES5 and ES6, and something
has partially changed, as illustrated by this example:
eval(var x=1; 12; while(true){ if (x) { x--; 42 } else { break } })
In ES5 and in implementations this returns 42, in ES6 this returns
undefined. The difference is here:
ES5 (12.6.2):
2. Repeat
a. Let exprRef be the result of evaluating Expression.
b. If ToBoolean(GetValue(exprRef)) is false, return (normal, V, empty).
c. Let stmt be the result of evaluating Statement.
d. If stmt.value is not empty, let V = stmt.value.
e. If stmt.type is not continue || stmt.target is not in the current
label set, then
i. If stmt.type is break and stmt.target is in the current label
set, then
1. Return (normal, V, empty).
ii. If stmt is an abrupt completion, return stmt.
In the example, 2.d does not apply for the second iteration of the loop
(the returned value is empty), and we are in the 2.e.i.1 case (local
break) so the returned value is patched in the completion statement.
ES6 (13.0.7 and 13.6.2.6)
the evaluation of the second iteration of the loop ends like this:
e. Let stmt be the result of evaluating Statement.
f. If LoopContinues (stmt, labelSet) is false, return Completion(stmt).
at this point we return (break, empty, empty) to the evaluation of the
iteration statement, which transforms it into a (normal, undefined,
empty).
The example I gave is different. Adapting it so that is resembles the
previous one:
eval(var x=1; a: { 12; while(true) { if (x) { x--; 42} else { break a; } }
})
This returns 12 in both ES5 and ES6 (the 12 gets patched in because of
the outer block evaluation), so the labeled statement conversion of
empty to undefined does not kick in.
Does this inconsistency matter?
Probably. In ES6 we are trying to “reform” completion values so, among other
things, program transformaions do have to worry too much about breaking the
specified specified completions values.
We found this by looking into loop unrolling, so it would be great if
completion values could propagate across loop iterations.
Best,
Alan
--
OpenPGP Key ID : 040D0A3B4ED2E5C7
signature.asc
Description: PGP signature
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: loop unrolling and completion values in ES6
On Apr 9, 2015, at 10:44 AM, Alan Schmitt alan.schm...@polytechnique.org
wrote:
1. Let sl be the result of evaluating StatementList.
2. ReturnIfAbrupt(sl).
3. Let s be the result of evaluating StatementListItem.
4. If s.[[type]] is throw, return Completion(s).
5. If s.[[value]] is empty, let V = sl.[[value]], otherwise let V =
s.[[value]].
6. Return Completion{[[type]]: s.[[type]], [[value]]: V, [[target]]:
s.[[target]]}.
The problem happens when the first statement of the body of the while
loop is a break: in that case the value from the previous iteration is
not carried over.
I agree, each kind of loop needs to do its equivalent of step 5 above before
checking for exit conditions, that is the opposite of what is currently
specified.
Allen
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Well-Known Symbols: Array item getter/setter
( note: you can view this message as a gist @
https://gist.github.com/kosich/375da99403c76bc75bbd )
Currently we can imitate Arrays only with objects, where we would
refer to a value at some position via referring to objects property (
with integer index being converted to a string )
```js
var arr = {
0 : zero,
1 : one
};
arr[ 1 ];
```
But we wouldn't get all those features that original Array has (like
length autoincremention, splice, split etc.)
So, the suggestion is to have WKS for getting and setting item in
array by index.
```js
get [ Symbol.Array.item ] ( index ){ /*returning code here*/ }
set [ Symbol.Array.item ] ( index ){ /*setter code here*/ }
```
-or-
```js
[ Symbol.Array.get ] ( index ){ /*returning code here*/ }
[ Symbol.Array.set ] ( index ){ /*setter code here*/ }
```
## Possible usecases
### readonly array
will throw if user tries to set item directly via index
```js
class ROArray extends Array {
constructor( initialValues ){
// init the array values here
}
[ Symbol.Array.set ] ( index ){
throw 'can`t set';
}
[ Symbol.Array.get ] ( index ){
return this[ index ];
}
}
```
### template-like behavior
items getter will wrap the value into a tag
```js
class LITemplateArray extends Array {
set tag ( tag ){
this._tag = tag;
}
[ Symbol.Array.get ] ( index ){
var tag = this._tag || 'li',
value = this[ index ];
return `${ tag }${value}/${tag}`;
}
}
```
/*this is my first thread here, so I'm sorry if being wrong somewhere*/
/*after googling around, I haven't found such suggestion. though could
easily miss that*/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Well-Known Symbols: Array item getter/setter
Proxies should be enough for this. Is there any reason not to use them?
On 09 Apr 2015, at 20:31, Kos Ddsky kos...@gmail.com wrote:
( note: you can view this message as a gist @
https://gist.github.com/kosich/375da99403c76bc75bbd
https://gist.github.com/kosich/375da99403c76bc75bbd )
Currently we can imitate Arrays only with objects, where we would refer to a
value at some position via referring to objects property ( with integer index
being converted to a string )
```js
var arr = {
0 : zero,
1 : one
};
arr[ 1 ];
```
But we wouldn't get all those features that original Array has (like length
autoincremention, splice, split etc.)
So, the suggestion is to have WKS for getting and setting item in array by
index.
```js
get [ Symbol.Array.item ] ( index ){ /*returning code here*/ }
set [ Symbol.Array.item ] ( index ){ /*setter code here*/ }
```
-or-
```js
[ Symbol.Array.get ] ( index ){ /*returning code here*/ }
[ Symbol.Array.set ] ( index ){ /*setter code here*/ }
```
## Possible usecases
### readonly array
will throw if user tries to set item directly via index
```js
class ROArray extends Array {
constructor( initialValues ){
// init the array values here
}
[ Symbol.Array.set ] ( index ){
throw 'can`t set';
}
[ Symbol.Array.get ] ( index ){
return this[ index ];
}
}
```
### template-like behavior
items getter will wrap the value into a tag
```js
class LITemplateArray extends Array {
set tag ( tag ){
this._tag = tag;
}
[ Symbol.Array.get ] ( index ){
var tag = this._tag || 'li',
value = this[ index ];
return `${ tag }${value}/${tag}`;
}
}
```
/*this is my first thread here, so I'm sorry if being wrong somewhere*/
/*after googling around, I haven't found such suggestion. though could easily
miss that*/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Well-Known Symbols: Array item getter/setter
On Apr 9, 2015, at 2:37 PM, Jordan Harband ljh...@gmail.com wrote: One advantage of this approach is that more spec magic can be implemented in terms of the language - it would also make subclassed arrays more versatile instead of having to always be a Proxy. see http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation Allen ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Well-Known Symbols: Array item getter/setter
One advantage of this approach is that more spec magic can be implemented
in terms of the language - it would also make subclassed arrays more
versatile instead of having to always be a Proxy.
On Thu, Apr 9, 2015 at 11:35 AM, Axel Rauschmayer a...@rauschma.de wrote:
Proxies should be enough for this. Is there any reason not to use them?
On 09 Apr 2015, at 20:31, Kos Ddsky kos...@gmail.com wrote:
( note: you can view this message as a gist @
https://gist.github.com/kosich/375da99403c76bc75bbd )
Currently we can imitate Arrays only with objects, where we would refer to a
value at some position via referring to objects property ( with integer index
being converted to a string )
```js
var arr = {
0 : zero,
1 : one
};
arr[ 1 ];
```
But we wouldn't get all those features that original Array has (like length
autoincremention, splice, split etc.)
So, the suggestion is to have WKS for getting and setting item in array by
index.
```js
get [ Symbol.Array.item ] ( index ){ /*returning code here*/ }
set [ Symbol.Array.item ] ( index ){ /*setter code here*/ }
```
-or-
```js
[ Symbol.Array.get ] ( index ){ /*returning code here*/ }
[ Symbol.Array.set ] ( index ){ /*setter code here*/ }
```
## Possible usecases
### readonly array
will throw if user tries to set item directly via index
```js
class ROArray extends Array {
constructor( initialValues ){
// init the array values here
}
[ Symbol.Array.set ] ( index ){
throw 'can`t set';
}
[ Symbol.Array.get ] ( index ){
return this[ index ];
}
}
```
### template-like behavior
items getter will wrap the value into a tag
```js
class LITemplateArray extends Array {
set tag ( tag ){
this._tag = tag;
}
[ Symbol.Array.get ] ( index ){
var tag = this._tag || 'li',
value = this[ index ];
return `${ tag }${value}/${tag}`;
}
}
```
/*this is my first thread here, so I'm sorry if being wrong somewhere*/
/*after googling around, I haven't found such suggestion. though could easily
miss that*/
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
Dr. Axel Rauschmayer
a...@rauschma.de
rauschma.de
___
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: loop unrolling and completion values in ES6
Alan Schmitt wrote: We found this by looking into loop unrolling, so it would be great if completion values could propagate across loop iterations. Definitely. Thanks for finding this! /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Well-Known Symbols: Array item getter/setter
1. one will have to provide access to all `Array.prototype.methods` 2. proxies will be slower 3. bad readability ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Well-Known Symbols: Array item getter/setter
An alternative that was discussed at one point was to invert this idea: * Arrays get the methods that Maps already have: `get(index)` and `set(index, value)`. Advantage: one could support negative indices. That is, the following two expressions would be equivalent. ```js arr.get(-1) arr.get(arr.length-1) ``` * Using brackets for accessing array elements is phased out. That may be easier to achieve and would fit in well with ES6 collections. On 09 Apr 2015, at 21:38, Allen Wirfs-Brock al...@wirfs-brock.com wrote: On Apr 9, 2015, at 2:37 PM, Jordan Harband ljh...@gmail.com mailto:ljh...@gmail.com wrote: One advantage of this approach is that more spec magic can be implemented in terms of the language - it would also make subclassed arrays more versatile instead of having to always be a Proxy. see http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation http://wiki.ecmascript.org/doku.php?id=strawman:object_model_reformation -- Dr. Axel Rauschmayer a...@rauschma.de rauschma.de ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Syntax sugar for partial application
FWIW: agreed with others, it looks a pretty pointless sugar. It doesn't seem to bring anything new or that needed to the language. -1 here On Thu, Apr 9, 2015 at 2:04 PM, liorean lior...@gmail.com wrote: Do we really need it? Your «foo(1, ?, 2);» is equivalent to «a=foo(1,a,2)». Your «foo(?, 1, ???);» is equivalent to «(a,...b)=foo(a,1,...b)». Your «foo(1, ???, 2);» is equivalent to «(...a)=foo(...[1,...a,2])». Also, the ? token is already taken by the ternary conditional operator. Do we really want to overload it here for a nullary operator/special form, when we have as low overhead syntax as we already do in fat arrows for doing the exact same thing? -- David liorean Andersson ___ 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: Syntax sugar for partial application
Do we really need it? Your «foo(1, ?, 2);» is equivalent to «a=foo(1,a,2)». Your «foo(?, 1, ???);» is equivalent to «(a,...b)=foo(a,1,...b)». Your «foo(1, ???, 2);» is equivalent to «(...a)=foo(...[1,...a,2])». Also, the ? token is already taken by the ternary conditional operator. Do we really want to overload it here for a nullary operator/special form, when we have as low overhead syntax as we already do in fat arrows for doing the exact same thing? -- David liorean Andersson ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
