Why is sparse still part of the description for [[ArrayIterationKind]]?
I'm not sure whether this is a bug or it's still open, so I've posted it here first -- sorry if this has already been discussed, I've tried to find related threads and bug reports but to no avail. As of Rev 22 of the ES6 spec, [[ArrayIterationKind]] is described as follows (§22.1.5.3): A string value that identifies what is to be returned for each element of the iteration. The possible values are: key, value, key+value, sparse:key, sparse:value, sparse:key+value. I haven't seen the sparse forms being referenced anywhere else, so I'm just checking whether they're actually needed or not. Is this just an oversight, or is it actually significant? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
On 29 Jan 2014 03:42, Brendan Eich bren...@mozilla.com wrote: And so we will go with 'chain'. I assume it has been pointed out before that Underscore/LoDash have popularised their own chain function/concept? http://underscorejs.org/#chaining Hopefully it's distant enough from Promise-world to alleviate most confusion, but I thought I'd point it out for completeness. On the flatMap name, as a Scala developer, I find it quite conveniently describes the flattening nature of the operation, although it only really works thanks to the parallel with map: M[A]#map(f: A = B): M[B] M[A]#flatMap(f: A = M[B]): M[B] (not M[M[B]] as it would with map - hence the flat) But given that 'then' is a sort of a mix of map/flatMap (and flatThen is terrible), I don't think there is an obvious parallel currently. Seeing as flatMap/chain is being discussed though, have there been plans to add a map method on Promises (that would map to a new Promise without unwrapping returned promises)? And have there been any discussion to add other monadic types to ES, eg Option/Maybe, Try, etc, or to make existing types support more monadic operations, eg Array.prototype.flatMap (or chain?). Thanks, and sorry if this has been discussed before (is there any way to catch up on such topics if it has, short of reading piles of minutes?). On 29 January 2014 03:42, Brendan Eich bren...@mozilla.com wrote: Quildreen Motta wrote: I suppose using names that don't give you a hint of the meaning of the operation fits perfectly Haskell's (and Scalaz's) Avoid Success At All Costs tradition lulz. And so we will go with 'chain'. /be ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- Sébastien Cevey Software Developer Please consider the environment before printing this email. -- Visit theguardian.com On your mobile, download the Guardian iPhone app theguardian.com/iphone and our iPad edition theguardian.com/iPad Save up to 57% by subscribing to the Guardian and Observer - choose the papers you want and get full digital access. Visit subscribe.theguardian.com This e-mail and all attachments are confidential and may also be privileged. If you are not the named recipient, please notify the sender and delete the e-mail and all attachments immediately. Do not disclose the contents to another person. You may not use the information for any purpose, or store, or copy, it in any way. Guardian News Media Limited is not liable for any computer viruses or other material transmitted with or as part of this e-mail. You should employ virus checking software. Guardian News Media Limited A member of Guardian Media Group plc Registered Office PO Box 68164 Kings Place 90 York Way London N1P 2AP Registered in England Number 908396 -- ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
While the getMyPromise question wasn't answered yet and still isn't
clear to me, from the other posts I think it can be reworded this way:
```js
var p1 = Promise.resolve(Promise.cast(1));
var p2 = Promise.cast(Promise.cast(1));
```
p1 and p2 will have a different internal state, but there is no way to
tell the difference between the two (and no way to write a regression
test to check that the internal state is correct), until in the future
a new method will be defined.
Is this correct? What about the case of:
```js
var p3 = new Promise(resolve = resolve(Promise.cast(1));
```
Will the state of p3 be more similar to that of p1 or that of p2?
I'll file a bug when I understand the situation better.
Regards,
Paolo
On 28/01/2014 21.07, Paolo Amadini wrote:
I don't have a background on the .flatMap level of abstraction. In the
following scenario, will users of getMyPromise() have a different
behavior with .flatMap if the library code used cast rather than
resolve? If so, this can definitely lead to confusion when .flatMap
is introduced in the future since the callers cannot be sure about
what the library did internally, assuming the library authors didn't
intentionally choose one or the other.
```js
// -- MyLibrary.js
function getMyPromise() {
var a = condition ? getMyOtherPromise() : value2;
return Promise.resolve(a);
}
function getMyOtherPromise() {
return Promise.resolve(value1);
}
```
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
On 29/01/2014 5.12, Kris Kowal wrote: In this case, a half pursuit of type purity is a side quest at the expense of users. Having two ways to resolve and two ways to observe a promise is unnecessarily confusing. In my experience, one method like then, that unwraps recursively, and one function, like Promise.cast, that automatically lifts if necessary, and then handlers that return into the waiting hands of Promise.cast are coherent and ergonomic. Having a choice between cast and resolve and a choice between then and chain, will leave developers unnecessarily confused and worried all the while they use or abandon Promises as too subtle. As an imperative programmer, I confirm I'm left worried and confused ;-) But I understand that functional programming might need more complexity. I would be less confused if functionality that is only relevant for functional programming would be separate and inaccessible by default, even if supported and optimized at the implementation level. For example: ```js let p1 = FunctionalPromise.accept(...) FunctionalPromise.chain(p1, ...) ``` And no Promise.accept or p1.chain methods to be chosen over Promise.cast and p1.then. Paolo ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
On 29 January 2014 10:45, Paolo Amadini paolo.02@amadzone.org wrote: On 29/01/2014 5.12, Kris Kowal wrote: In this case, a half pursuit of type purity is a side quest at the expense of users. Having two ways to resolve and two ways to observe a promise is unnecessarily confusing. In my experience, one method like then, that unwraps recursively, and one function, like Promise.cast, that automatically lifts if necessary, and then handlers that return into the waiting hands of Promise.cast are coherent and ergonomic. Having a choice between cast and resolve and a choice between then and chain, will leave developers unnecessarily confused and worried all the while they use or abandon Promises as too subtle. As an imperative programmer, I confirm I'm left worried and confused ;-) But I understand that functional programming might need more complexity. It is, actually, more simplicity. The concept of `Promise.resolve` and `Promise.chain` is simpler than `Promise.cast` and `Promise.then` (i.e.: they represent orthogonal concepts, not complected). `Promise.cast` and `Promise.then` may be, arguably, *easier* to work with, from a user POV, since you don't need to make as many choices. I would argue that it would make more sense to write `cast` and `then` in terms of `resolve` and `chain`, however. But this seems to have already been decided. Answering your previous question: ```js var p1 = Promise.resolve(Promise.cast(1)); var p2 = Promise.cast(Promise.cast(1)); ``` `p1` will be a `Promise(Promise(1))`, whereas `p2` will be `Promise(1)` — IOW, `Promise.resolve` will just put anything inside of a `Promise`, regardless of that being a promise or a regular value, whereas `Promise.cast` will put the innermost value that is not a promise inside of a promise. ```js var p3 = new Promise(resolve = resolve(Promise.cast(1)); // is the same as: var p3 = Promise.resolve(Promise.cast(1)) ``` -- -- Quildreen (Soreλ\a) Motta (http://robotlolita.github.io/http://killdream.github.com/ ) *— JavaScript Alchemist / Minimalist Designer / PLT hobbyist —* ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Promise.cast and Promise.resolve
It is, actually, more simplicity. The concept of `Promise.resolve` and `Promise.chain` is simpler than `Promise.cast` and `Promise.then` (i.e.: they represent orthogonal concepts, not complected). `Promise.cast` and `Promise.then` may be, arguably, *easier* to work with, from a user POV, since you don't need to make as many choices. I would argue that it would make more sense to write `cast` and `then` in terms of `resolve` and `chain`, however. But this seems to have already been decided. It does make more sense, and from my point of view it's not decided. What is decided is the AP2 design. That is: 1) promises are fully parametric and, 2) `then` recursively unwraps the *input* to its callbacks. For the sake of coherency (aka conceptual integrity), `then` needs to be written in terms of `chain`. This issue needs to be resolved ASAP, however, since promises are making their way into engines now. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: Why is sparse still part of the description for [[ArrayIterationKind]]?
it's and editorial bug. I forgot to delete that text from the description. Allen On Jan 29, 2014, at 2:38 AM, Qantas 94 Heavy wrote: I'm not sure whether this is a bug or it's still open, so I've posted it here first -- sorry if this has already been discussed, I've tried to find related threads and bug reports but to no avail. As of Rev 22 of the ES6 spec, [[ArrayIterationKind]] is described as follows (§22.1.5.3): A string value that identifies what is to be returned for each element of the iteration. The possible values are: key, value, key+value, sparse:key, sparse:value, sparse:key+value. I haven't seen the sparse forms being referenced anywhere else, so I'm just checking whether they're actually needed or not. Is this just an oversight, or is it actually significant? ___ 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
restrictions on module import export names
I'm wondering if this is valid (or should be): // a.js var foo = 1; export foo as 'a.b.c'; // b.js import 'a.b.c' as foo from a.js The reason I ask is Modules appear to support have any valid property name (anything) as an export if the Module is defined directly using newModule. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on module import export names
// a.js var foo = 1; export foo as 'a.b.c'; // b.js import 'a.b.c' as foo from a.js That is not valid. Export binding names (where you have 'a.b.c') must be IdentifierName. ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on module import export names
I assume that I can access this like so:
var mod = newModule({'a.b.c':1})
use(mod['a.b.c']);
It isn't clear to me why imports and export names are restricted.
On Wed, Jan 29, 2014 at 8:40 AM, Kevin Smith zenpars...@gmail.com wrote:
// a.js
var foo = 1;
export foo as 'a.b.c';
// b.js
import 'a.b.c' as foo from a.js
That is not valid. Export binding names (where you have 'a.b.c') must be
IdentifierName.
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on module import export names
There are still unresolved issues in the Rev22 spec. with the newModule (or
possibly new Module) API. t probably needs to say that any property names must
conform to IdentifierName.
The grammar requirement of IdentifierName is intentional and I don't believe
there is any intent to allow that restriction to be circumvented via the Module
API.
Allen
On Jan 29, 2014, at 8:54 AM, John Lenz wrote:
I assume that I can access this like so:
var mod = newModule({'a.b.c':1})
use(mod['a.b.c']);
It isn't clear to me why imports and export names are restricted.
On Wed, Jan 29, 2014 at 8:40 AM, Kevin Smith zenpars...@gmail.com wrote:
// a.js
var foo = 1;
export foo as 'a.b.c';
// b.js
import 'a.b.c' as foo from a.js
That is not valid. Export binding names (where you have 'a.b.c') must be
IdentifierName.
___
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: restrictions on module import export names
related, is it possible to export anonymous objects?
from looking at the spec it would seem that
```js
let foo = 1;
export foo as default;
```
would be allowed but
```js
export 1 as default;
```
would not
so to export an object that doesn't already have a name you'd have to
something like:
```js
export let default = 1;
```
less contrived examples of this in practice are exporting the results of a
function (extremely common in node, for me at least) and exporting an array:
```js
export let default = foo();
export let default = [thing1, thing2];
```
is there a reason
```js
export expression;
```
doesn't desuger to
```js
export const default = expression;
```
or am I missing something?
On Wed, Jan 29, 2014 at 12:35 PM, Allen Wirfs-Brock
al...@wirfs-brock.comwrote:
There are still unresolved issues in the Rev22 spec. with the newModule
(or possibly new Module) API. t probably needs to say that any property
names must conform to IdentifierName.
The grammar requirement of IdentifierName is intentional and I don't
believe there is any intent to allow that restriction to be circumvented
via the Module API.
Allen
On Jan 29, 2014, at 8:54 AM, John Lenz wrote:
I assume that I can access this like so:
var mod = newModule({'a.b.c':1})
use(mod['a.b.c']);
It isn't clear to me why imports and export names are restricted.
On Wed, Jan 29, 2014 at 8:40 AM, Kevin Smith zenpars...@gmail.com wrote:
// a.js
var foo = 1;
export foo as 'a.b.c';
// b.js
import 'a.b.c' as foo from a.js
That is not valid. Export binding names (where you have 'a.b.c') must be
IdentifierName.
___
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
--
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on module import export names
`export default 1` works.
https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports
ExportDeclaration :
...
export default AssignmentExpression ;
On Wed, Jan 29, 2014 at 11:03 AM, Calvin Metcalf
calvin.metc...@gmail.comwrote:
related, is it possible to export anonymous objects?
from looking at the spec it would seem that
```js
let foo = 1;
export foo as default;
```
would be allowed but
```js
export 1 as default;
```
would not
so to export an object that doesn't already have a name you'd have to
something like:
```js
export let default = 1;
```
less contrived examples of this in practice are exporting the results of a
function (extremely common in node, for me at least) and exporting an array:
```js
export let default = foo();
export let default = [thing1, thing2];
```
is there a reason
```js
export expression;
```
doesn't desuger to
```js
export const default = expression;
```
or am I missing something?
On Wed, Jan 29, 2014 at 12:35 PM, Allen Wirfs-Brock al...@wirfs-brock.com
wrote:
There are still unresolved issues in the Rev22 spec. with the newModule
(or possibly new Module) API. t probably needs to say that any property
names must conform to IdentifierName.
The grammar requirement of IdentifierName is intentional and I don't
believe there is any intent to allow that restriction to be circumvented
via the Module API.
Allen
On Jan 29, 2014, at 8:54 AM, John Lenz wrote:
I assume that I can access this like so:
var mod = newModule({'a.b.c':1})
use(mod['a.b.c']);
It isn't clear to me why imports and export names are restricted.
On Wed, Jan 29, 2014 at 8:40 AM, Kevin Smith zenpars...@gmail.comwrote:
// a.js
var foo = 1;
export foo as 'a.b.c';
// b.js
import 'a.b.c' as foo from a.js
That is not valid. Export binding names (where you have 'a.b.c') must
be IdentifierName.
___
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
--
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
--
erik
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on module import export names
On Wed, Jan 29, 2014 at 2:00 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: `export default 1` works. https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports ExportDeclaration : export default AssignmentExpression ; I think that just exports the value 1 with the name default. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on module import export names
So the following are equivalent? ```js export default foo(); export let default = foo(); ``` On Jan 29, 2014 5:19 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:00 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: `export default 1` works. https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports ExportDeclaration : export default AssignmentExpression ; I think that just exports the value 1 with the name default. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: restrictions on module import export names
You cannot have a declaration with default as the IdentifierName, since that is a reserved word. So `export let default = foo();` is not possible. From: es-discuss es-discuss-boun...@mozilla.org on behalf of Calvin Metcalf calvin.metc...@gmail.com Sent: Wednesday, January 29, 2014 18:25 To: Jason Orendorff Cc: EcmaScript; Erik Arvidsson Subject: Re: restrictions on module import export names So the following are equivalent? ```js export default foo(); export let default = foo(); ``` On Jan 29, 2014 5:19 PM, Jason Orendorff jason.orendo...@gmail.commailto:jason.orendo...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:00 PM, Erik Arvidsson erik.arvids...@gmail.commailto:erik.arvids...@gmail.com wrote: `export default 1` works. https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports ExportDeclaration : export default AssignmentExpression ; I think that just exports the value 1 with the name default. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
RE: restrictions on module import export names
*would be equivalent of it was allowed On Jan 29, 2014 6:30 PM, Domenic Denicola dome...@domenicdenicola.com wrote: You cannot have a declaration with default as the IdentifierName, since that is a reserved word. So `export let default = foo();` is not possible. -- *From:* es-discuss es-discuss-boun...@mozilla.org on behalf of Calvin Metcalf calvin.metc...@gmail.com *Sent:* Wednesday, January 29, 2014 18:25 *To:* Jason Orendorff *Cc:* EcmaScript; Erik Arvidsson *Subject:* Re: restrictions on module import export names So the following are equivalent? ```js export default foo(); export let default = foo(); ``` On Jan 29, 2014 5:19 PM, Jason Orendorff jason.orendo...@gmail.com wrote: On Wed, Jan 29, 2014 at 2:00 PM, Erik Arvidsson erik.arvids...@gmail.com wrote: `export default 1` works. https://people.mozilla.org/~jorendorff/es6-draft.html#sec-exports ExportDeclaration : export default AssignmentExpression ; I think that just exports the value 1 with the name default. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on module import export names
On Wed, Jan 29, 2014 at 3:39 PM, Calvin Metcalf calvin.metc...@gmail.com wrote: *would be equivalent of it was allowed [...] So the following are equivalent? ```js export default foo(); export let default = foo(); ``` Yes. -j ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on module import export names
ok so would this be accurate https://gist.github.com/calvinmetcalf/8701624 ?
the syntax does make it impossible to write something equivalent to
```js
let app = module.exports = require('express')();
```
On Wed, Jan 29, 2014 at 6:40 PM, Jason Orendorff
jason.orendo...@gmail.comwrote:
On Wed, Jan 29, 2014 at 3:39 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
*would be equivalent of it was allowed
[...]
So the following are equivalent?
```js
export default foo();
export let default = foo();
```
Yes.
-j
--
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
RE: restrictions on module import export names
I would really encourage you to read the spec grammar.
```js
export foo();
```
This is not allowed by the grammar; there is no form `export expression`
```js
export default let a = [thing1, thing2];
```
This is not allowed by the grammar; `let a = [thing1, thing2]` is not an
AssignmentExpression.
```js
let app = module.exports = require('express')();
```
Try
```js
import express from express;
let app = express();
export default app;
```
From: Calvin Metcalf [mailto:calvin.metc...@gmail.com]
Sent: Wednesday, January 29, 2014 21:46
To: Jason Orendorff
Cc: Domenic Denicola; Erik Arvidsson; EcmaScript
Subject: Re: restrictions on module import export names
ok so would this be accurate https://gist.github.com/calvinmetcalf/8701624 ?
the syntax does make it impossible to write something equivalent to
```js
let app = module.exports = require('express')();
```
On Wed, Jan 29, 2014 at 6:40 PM, Jason Orendorff jason.orendo...@gmail.com
wrote:
On Wed, Jan 29, 2014 at 3:39 PM, Calvin Metcalf
calvin.metc...@gmail.com wrote:
*would be equivalent of it was allowed
[...]
So the following are equivalent?
```js
export default foo();
export let default = foo();
```
Yes.
-j
--
-Calvin W. Metcalf
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on module import export names
```js
let app = module.exports = require('express')();
```
Not impossible. Possibly:
import express from express;
let app = express();
export { app as default };
I think you're attempting to optimize edge cases.
Also, I agree with Domenic. Read the grammar for the current spec and try
not to post syntax errors that might lead others astray : )
___
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
restrictions on let declarations
I have some old notes that says that let can't be used in some context where a var could like: if (a) let x = 2; In my perusal of the spec I don't see that this is the case now. Can someone confirm that for me? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
Re: restrictions on let declarations
It falls out of the grammar. IfStatement can only contain Statement which does not include Declaration without going through a BlockStatement. On Wed, Jan 29, 2014 at 9:57 PM, John Lenz concavel...@gmail.com wrote: I have some old notes that says that let can't be used in some context where a var could like: if (a) let x = 2; In my perusal of the spec I don't see that this is the case now. Can someone confirm that for me? ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss -- erik ___ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
