Array Comprehensions

# Ryan Birmingham (a year ago)

Hello all,

I frequently find myself desiring a short array or generator comprehension syntax. I'm aware that there are functional ways around use of comprehension syntax, but I personally (at least) love the syntax in the ES reference ( developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Array_comprehensions ).

The best previous discussion on this that I found was six years old ( esdiscuss.org/topic/array-comprehensions-shorter-syntax) and answers some of my questions, raising others. That said, I wanted to ask:

  • Why is the Comprehension Syntax in the reference yet not more standard? It feels almost like a tease.
  • How do you usually approach or avoid this issue?
  • Do you think we should look at improving and standardizing the comprehension syntax?

Thank you all for humoring me,

-Ryan Birmingham

# T.J. Crowder (a year ago)

Given Array.prototype.filter, Array.prototype.map, and other utilities you can create combined with arrow functions, what is it about using syntax for this instead that draws you? For me, the syntax doesn't add any expressiveness, e.g. I don't see that this:

const numbers = [1, 2, 3];
const doubled = [for (i of numbers) i * 2];

is any more expressive than

const numbers = [1, 2, 3];
const doubled = numbers.map(i => i * 2);

How do you usually approach or avoid this issue?

I use filter, map, and such.

Do you think we should look at improving and standardizing the

comprehension syntax?

I don't see much percentage in it, FWIW, barring hearing more about the motivations for having it.

-- T.J.

# Gil Tayar (a year ago)

Forgive me if I'm wrong, but the double-for comprehension (e.g. [for (i of numbers) for (j of letters) i + j]) can't be easily expressed in JS because there's no flatMap.

# Tab Atkins Jr. (a year ago)

On Mon, Feb 6, 2017 at 9:47 AM, Gil Tayar <gil at tayar.org> wrote:

Forgive me if I'm wrong, but the double-for comprehension (e.g. [for (i of numbers) for (j of letters) i + j]) can't be easily expressed in JS because there's no flatMap.

Correct. (Which is why we need to add it.)

Aside: double-for in array comprehensions is only Pythonic in very simple cases; it's usually quite hard to read. The functional version is somewhat better imo:

numbers.flatMap(i => letters.map(j => i+j));

# David Bruant (a year ago)

Le 06/02/2017 à 17:59, Ryan Birmingham a écrit :

Hello all,

I frequently find myself desiring a short array or generator comprehension syntax. I'm aware that there are functional ways around use of comprehension syntax, but I personally (at least) love the syntax in the ES reference (developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Array_comprehensions).

The best previous discussion on this that I found was six years old (esdiscuss.org/topic/array-comprehensions-shorter-syntax) and answers some of my questions, raising others. That said, I wanted to ask:

  • Why is the Comprehension Syntax in the reference yet not more standard? It feels almost like a tease.

Proposals to change the standard are listed here : tc39/proposals The process for a feature to become standard is described here : tc39.github.io/process-document

  • How do you usually approach or avoid this issue?
  • Do you think we should look at improving and standardizing the comprehension syntax?

Some might argue it is yet another instance of "superficial sugar obsession" [1] :-p I don't know where I stand personally.

In any case, if you want to start, write down a proposal (can be 20 lines in a gist [2]) including programs that are hard to express in JavaScript and which readability would significantly be improved with the new syntax. Perhaps submit it to the mailing-list and try to find a "TC39 champion" (criterion to enter stage 1). At the very least, the proposal will be listed in the stage 0 proposals list [3].

David

[1] twitter.com/mikeal/status/828674319651786754 [2] gist.github.com [3] tc39/proposals/blob/master/stage-0-proposals.md

# Bob Myers (a year ago)

On Tue, Feb 7, 2017 at 6:58 PM, David Bruant <bruant.d at gmail.com> wrote:

At the very least, the proposal will be listed in the stage 0 proposals list [3].

My understanding is that a champion is required even to become stage 0.

# Ryan Birmingham (a year ago)

It wasn't clear from the documentation; who can or cannot be a champion?

-Ryan Birmingham

# kdex (a year ago)

AFAIK, only TC39 members can champion a proposal.

If you're not a member, you could still write a proposal and hope that some TC39 member is interested in championing it.

# Cyril Auburtin (a year ago)

I often use

Array.from({length: n}, (_, i) => i**2)
Array.from({length: n}, (_, i) => Array.from({length: n}, (_, j) => i*j))
[].concat(...Array.from({length: n}, (_, i) => Array.from({length: n}, (_, j) => ({i,j,v:i*j})))) // flattened

2017-02-07 23:13 GMT+01:00 kdex <kdex at kdex.de>:

# Herby Vojčík (a year ago)

Ryan Birmingham wrote:

Hello all,

I frequently find myself desiring a short array or generator comprehension syntax. I'm aware that there are functional ways around use of comprehension syntax, but I personally (at least) love the syntax in the ES reference (developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Array_comprehensions).

The best previous discussion on this that I found was six years old (esdiscuss.org/topic/array-comprehensions-shorter-syntax) and answers some of my questions, raising others. That said, I wanted to ask:

  • Why is the Comprehension Syntax in the reference yet not more standard? It feels almost like a tease.

IIRC, it was discussed here throroughly for ES6 (~2yrs ago?) and it was rejected in favour of .map/.filter/arrays fns.

# Allen Wirfs-Brock (a year ago)