@ liorean,

> For the record, what I can see, the code in the example is broken in
another way as well, the «i» in the reality example is not the variable
name used in the for-of.


You're right the second example is broken.
I can not edit my messages, sorry.

```js
Array.prototype.concat(...[ for (i of [x, y]) i ]);
```


@Mark S. Miller,

> Dave Herman did an excellent presentation at one of the TC39 meetings
that convinced us all to drop comprehension syntax from ES6. I remember it
surprised us all including, earlier Dave, which led to his presentation.
Anyone have a link?

> The arguments that I remember as most significant are a) When you look as
how much syntactic convenience comprehensions provide above explicit calls
to higher-order operations (assuming we have .map, .filter, as well as the
currently absent .flatMap) and arrow functions, the answer is not much. b)
When your comprehensions involve only those ho operations, fine. But as
soon as you try to mix in some other ho operation, such as e.g., a reduce,
if you started with a comprehension you're gonna create a mess. OTOH, if
you were starting with code explicitly calling ho operations, then there's
nothing confusing or unnatural mixing in some others.
I can not agree with this approach, [many languages](

http://en.wikipedia.org/wiki/List_comprehension) have this functionality


For example:

```js
var files = function (data) {
let result = [];

for (let path of data) {
result.push(...fs.readdirSync(path));
}

return result;
}
```

I believe that this code is awkward and not as beautiful as the possible
alternatives:


```js
var files = function (data) {
   return [ for (path of data) ...fs.readdirSync(path) ];
}
```

or

```js
var files = function (data) {
   return data.map(path => ...fs.readdirSync(path));
}
```





2015-04-15 21:27 GMT+03:00 Mark S. Miller <erights at google.com>:

> Dave Herman did an excellent presentation at one of the TC39 meetings that
> convinced us all to drop comprehension syntax from ES6. I remember it
> surprised us all including, earlier Dave, which led to his presentation.
> Anyone have a link?
>
> The arguments that I remember as most significant are
> a) When you look as how much syntactic convenience comprehensions provide
> above explicit calls to higher-order operations (assuming we have .map,
> .filter, as well as the currently absent .flatMap) and arrow functions, the
> answer is not much.
> b) When your comprehensions involve only those ho operations, fine. But as
> soon as you try to mix in some other ho operation, such as e.g., a reduce,
> if you started with a comprehension you're gonna create a mess. OTOH, if
> you were starting with code explicitly calling ho operations, then there's
> nothing confusing or unnatural mixing in some others.
>
> IMO, #a was necessary to convince me. YAGNI. Given #a, #b was sufficient.
>
> Dave, if I've misrepresented you in any way, please correct. Thanks.
>
>
>
>
> On Wed, Apr 15, 2015 at 10:20 AM, Axel Rauschmayer <axel at rauschma.de>
> wrote:
>
>> It’s important to keep in mind that there is no official version of array
>> comprehensions, at the moment. So that is something to keep in mind
>> whenever they are added to the language.
>>
>> I’d probably implement flatMap() and use it if I ever needed to do
>> something like this.
>>
>> On 15 Apr 2015, at 18:34, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
>>
>> On Wed, Apr 15, 2015 at 9:31 AM, Jeremy Martin <jmar777 at gmail.com> wrote:
>>
>> Why not just `[...x, ...y]`?
>>
>>
>> Obviously that's a solution to the trivial example that monolithed
>> provided, but it's not a solution to the more general problem he's
>> alluding to, where you're doing a comprehension and want to insert two
>> or more elements into the result in a single iteration.
>>
>> ~TJ
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>> --
>> Dr. Axel Rauschmayer
>> axel at rauschma.de
>> rauschma.de
>>
>>
>>
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
>
> --
>     Cheers,
>     --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20150415/9899c002/attachment.html>

@ liorean,

> For the record, what I can see, the code in the example is broken in
another way as well, the «i» in the reality example is not the variable
name used in the for-of.


You're right the second example is broken.
I can not edit my messages, sorry.

```js
Array.prototype.concat(...[ for (i of [x, y]) i ]);
```


@Mark S. Miller,

> Dave Herman did an excellent presentation at one of the TC39 meetings
that convinced us all to drop comprehension syntax from ES6. I remember it
surprised us all including, earlier Dave, which led to his presentation.
Anyone have a link?

> The arguments that I remember as most significant are a) When you look as
how much syntactic convenience comprehensions provide above explicit calls
to higher-order operations (assuming we have .map, .filter, as well as the
currently absent .flatMap) and arrow functions, the answer is not much. b)
When your comprehensions involve only those ho operations, fine. But as
soon as you try to mix in some other ho operation, such as e.g., a reduce,
if you started with a comprehension you're gonna create a mess. OTOH, if
you were starting with code explicitly calling ho operations, then there's
nothing confusing or unnatural mixing in some others.

I can not agree with this approach, [many languages](http://en.wikipedia.org/wiki/List_comprehension) have this functionality


For example:

```js
var files = function (data) {
    let result = [];

    for (let path of data) {
       result.push(...fs.readdirSync(path));
    }

    return result;
}
```

I believe that this code is awkward and not as beautiful as the possible
alternatives:


```js
var files = function (data) {
   return [ for (path of data) ...fs.readdirSync(path) ];
}
```

or

```js
var files = function (data) {
   return data.map(path => ...fs.readdirSync(path));
}
```

@ liorean,

> For the record, what I can see, the code in the example is broken in
another way as well, the «i» in the reality example is not the variable
name used in the for-of.


You're right the second example is broken.
I can not edit my messages, sorry.

```js
Array.prototype.concat(...[ for (i of [x, y]) i ]);
```


@Mark S. Miller,

> Dave Herman did an excellent presentation at one of the TC39 meetings
that convinced us all to drop comprehension syntax from ES6. I remember it
surprised us all including, earlier Dave, which led to his presentation.
Anyone have a link?

> The arguments that I remember as most significant are a) When you look as
how much syntactic convenience comprehensions provide above explicit calls
to higher-order operations (assuming we have .map, .filter, as well as the
currently absent .flatMap) and arrow functions, the answer is not much. b)
When your comprehensions involve only those ho operations, fine. But as
soon as you try to mix in some other ho operation, such as e.g., a reduce,
if you started with a comprehension you're gonna create a mess. OTOH, if
you were starting with code explicitly calling ho operations, then there's
nothing confusing or unnatural mixing in some others.

I can not agree with this approach, [many languages](http://en.wikipedia.org/wiki/List_comprehension) have this functionality


For example:

```js
var files = function (data) {
    let result = [];

    for (let path of data) {
       result.push(...fs.readdirSync(path));
    }

    return result;
}
```

I believe that this code is awkward and not as beautiful as the possible
alternatives:


```js
var files = function (data) {
   return [ for (path of data) ...fs.readdirSync(path) ];
}
```

or

```js
var files = function (data) {
   return data.map(path => ...fs.readdirSync(path));
}
```





2015-04-15 21:27 GMT+03:00 Mark S. Miller <erights at google.com>:

@ liorean,

> For the record, what I can see, the code in the example is broken in
another way as well, the «i» in the reality example is not the variable
name used in the for-of.


You're right the second example is broken.
I can not edit my messages, sorry.

```js
Array.prototype.concat(...[ for (i of [x, y]) i ]);
```


@Mark S. Miller,

> Dave Herman did an excellent presentation at one of the TC39 meetings
that convinced us all to drop comprehension syntax from ES6. I remember it
surprised us all including, earlier Dave, which led to his presentation.
Anyone have a link?

> The arguments that I remember as most significant are a) When you look as
how much syntactic convenience comprehensions provide above explicit calls
to higher-order operations (assuming we have .map, .filter, as well as the
currently absent .flatMap) and arrow functions, the answer is not much. b)
When your comprehensions involve only those ho operations, fine. But as
soon as you try to mix in some other ho operation, such as e.g., a reduce,
if you started with a comprehension you're gonna create a mess. OTOH, if
you were starting with code explicitly calling ho operations, then there's
nothing confusing or unnatural mixing in some others.

I can not agree with this approach, [many languages](

http://en.wikipedia.org/wiki/List_comprehension) have this functionality


For example:

```js
var files = function (data) {
    let result = [];

    for (let path of data) {
       result.push(...fs.readdirSync(path));
    }

    return result;
}
```

I believe that this code is awkward and not as beautiful as the possible
alternatives:


```js
var files = function (data) {
   return [ for (path of data) ...fs.readdirSync(path) ];
}
```

or

```js
var files = function (data) {
   return data.map(path => ...fs.readdirSync(path));
}
```





2015-04-15 21:27 GMT+03:00 Mark S. Miller <erights at google.com>:

@ liorean,

> For the record, what I can see, the code in the example is broken in
another way as well, the «i» in the reality example is not the variable
name used in the for-of.


You're right the second example is broken.
I can not edit my messages, sorry.

```js
Array.prototype.concat(...[ for (i of [x, y]) i ]);
```


@Mark S. Miller,

> Dave Herman did an excellent presentation at one of the TC39 meetings
that convinced us all to drop comprehension syntax from ES6. I remember it
surprised us all including, earlier Dave, which led to his presentation.
Anyone have a link?

> The arguments that I remember as most significant are a) When you look as
how much syntactic convenience comprehensions provide above explicit calls
to higher-order operations (assuming we have .map, .filter, as well as the
currently absent .flatMap) and arrow functions, the answer is not much. b)
When your comprehensions involve only those ho operations, fine. But as
soon as you try to mix in some other ho operation, such as e.g., a reduce,
if you started with a comprehension you're gonna create a mess. OTOH, if
you were starting with code explicitly calling ho operations, then there's
nothing confusing or unnatural mixing in some others.

I can not agree with this approach, [many languages](

http://en.wikipedia.org/wiki/List_comprehension) have this functionality


For example:

```js
var files = function (data) {
let result = [];

for (let path of data) {
result.push(...fs.readdirSync(path));
}

return result;
}
```

I believe that this code is awkward and not as beautiful as the possible
alternatives:


```js
var files = function (data) {
   return [ for (path of data) ...fs.readdirSync(path) ];
}
```

or

```js
var files = function (data) {
   return data.map(path => ...fs.readdirSync(path));
}
```





2015-04-15 21:27 GMT+03:00 Mark S. Miller <erights at google.com>:

@ liorean,

> For the record, what I can see, the code in the example is broken in

another way as well, the «i» in the reality example is not the variable
name used in the for-of.


You're right the second example is broken.
I can not edit my messages, sorry.

```js
Array.prototype.concat(...[ for (i of [x, y]) i ]);
```


@Mark S. Miller,

> Dave Herman did an excellent presentation at one of the TC39 meetings
that convinced us all to drop comprehension syntax from ES6. I remember it
surprised us all including, earlier Dave, which led to his presentation.
Anyone have a link?

> The arguments that I remember as most significant are a) When you look as
how much syntactic convenience comprehensions provide above explicit calls
to higher-order operations (assuming we have .map, .filter, as well as the
currently absent .flatMap) and arrow functions, the answer is not much. b)
When your comprehensions involve only those ho operations, fine. But as
soon as you try to mix in some other ho operation, such as e.g., a reduce,
if you started with a comprehension you're gonna create a mess. OTOH, if
you were starting with code explicitly calling ho operations, then there's
nothing confusing or unnatural mixing in some others.

I can not agree with this approach, [many languages](

http://en.wikipedia.org/wiki/List_comprehension) have this functionality


For example:

```js
var files = function (data) {
let result = [];

for (let path of data) {
result.push(...fs.readdirSync(path));
}

return result;
}
```

I believe that this code is awkward and not as beautiful as the possible
alternatives:


```js
var files = function (data) {
   return [ for (path of data) ...fs.readdirSync(path) ];
}
```

or

```js
var files = function (data) {
   return data.map(path => ...fs.readdirSync(path));
}
```





2015-04-15 21:27 GMT+03:00 Mark S. Miller <erights at google.com>:

@ liorean,

> For the record, what I can see, the code in the example is broken in

another way as well, the «i» in the reality example is not the variable
name used in the for-of.


You're right the second example is broken.
I can not edit my messages, sorry.

```js
Array.prototype.concat(...[ for (i of [x, y]) i ]);
```


@Mark S. Miller,

> Dave Herman did an excellent presentation at one of the TC39 meetings

that convinced us all to drop comprehension syntax from ES6. I remember it
surprised us all including, earlier Dave, which led to his presentation.
Anyone have a link?

> The arguments that I remember as most significant are a) When you look as

how much syntactic convenience comprehensions provide above explicit calls
to higher-order operations (assuming we have .map, .filter, as well as the
currently absent .flatMap) and arrow functions, the answer is not much. b)
When your comprehensions involve only those ho operations, fine. But as
soon as you try to mix in some other ho operation, such as e.g., a reduce,
if you started with a comprehension you're gonna create a mess. OTOH, if
you were starting with code explicitly calling ho operations, then there's
nothing confusing or unnatural mixing in some others.

I can not agree with this approach, [many languages](

http://en.wikipedia.org/wiki/List_comprehension) have this functionality


For example:

```js
var files = function (data) {
let result = [];

for (let path of data) {
result.push(...fs.readdirSync(path));
}

return result;
}
```

I believe that this code is awkward and not as beautiful as the possible
alternatives:


```js
var files = function (data) {
   return [ for (path of data) ...fs.readdirSync(path) ];
}
```

or

```js
var files = function (data) {
   return data.map(path => ...fs.readdirSync(path));
}
```





2015-04-15 21:27 GMT+03:00 Mark S. Miller <erights at google.com>: