Array comprehension syntax

[Brendan Eich]

Allen Wirfs-Brock wrote:
> On Sep 22, 2012, at 2:52 PM, Brendan Eich wrote:
>
>> Allen Wirfs-Brock wrote:
>>>> My personal bias, is that comprehensions are just sugar that are best used to express relatively simple and common construction use cases.  Complicated sequences of |for| and |if| clauses will be rarely seen and hence less understandable than the equivalent explicit looping expansions.
>> Ok, but this doesn't help get your solution to the inherent tension between "not using comprehensions for complicated cases" vs. "distaste for nanny syntax restrictions." :-|
>
> My nanny remark was in regard to Jason's suggestion of requiring a ConditionalExpression rather than an AssignmentExpression in if clauses.  eg, forbidding: if  x=3

This is far less nanny-ish and better motivated than preventing 
interleaved 'if's.

The desugaring of comprehensions is straightforward. Nannying over it in 
one case ('if' in middle) but not another ('if' at end) is inconsistent 
as well as nanny-ish. The expression grammar in the 'if' condition is a 
subtler matter.

>>> 2) a)  one or more [for] clauses followed by a single optional if clause (what is currently in the draft)
>
> actually what I meant to say was that personal preference for ES6 comprehensions, in increasing complexity order is:
>    1) [a non-starter alternative]

It's pretty disharmonious, also not respectful of the champions model, 
to keep on like this :-(.

>    2) a single for clause followed by a single optional if clause

"Two-dimensional" flattened comprehensions are useful and Python 
supports them, and so do SpiderMonkey and Rhino.

Given 'if' and the end, the two or more 'for' heads mean 'if' in the 
middle is necessary to avoid unwanted iteration in some cases.

>    3) one or more for clauses followed by a single optional if clause (what is in the current draft)

Yes, but your listing preferences or what's current says nothing about 
*why* anyone should prefer what you say you prefer!

>    4) a sequence where each element consists of a for clause and an optional if clause

What do you mean by "sequence"?

But let's not digress. This is a precedent-free and anti-champion notion.

>> How is this not a nanny syntax restriction? The desugaring works without issue for either of
>>
>> [x*y for x in range(XDIM) for y in range(YDIM)if x&  1 ]
>> [x*y for x in range(XDIM) if x&  1 for y in range(YDIM)]
>>
>> but the last has the virtue of skipping the y iteration for even x values.
>
> (don't you need to use of instead of in)

(Yes, this is something I'm going to have to validate in a JS shell and 
then make paren-free -- I write Python by default for comprehensions.)

> I don't think this is a nanny syntax issue as it doesn't involve trying to make it impossible to express something that is likely erroneous.

Neither does a ConditionalExpression rather than Expression for 'if'!

Your argument that one can always write loops out cuts both ways. Use it 
consistently, please.

>    Instead it is a simplicity issue. "a sequence of for clauses followed by an optional if clause" is strictly simpler to express and understand than "a sequence  where each element consists of a for clause and an optional if clause".

Simpler counting what complexity beans? Either way:

[x*y for x of range(XDIM) for y of range(YDIM) if x&  1]
[x*y for x of range(XDIM) if x&  1 for y of range(YDIM)]


we have two 'for's and one 'if'. Either way the desugaring or mental 
translation after the comprehension expression on the left is purely 
left-to-right. Same bean-count.

Specifiy your beans!

>    If use of non-trailing if clause is quite rare, then it may be adding unneeded complexity to the language  to support them, since there are already other ways to express the same rare thing.

Arguing about rarity is not arguing about complexity. You shifted 
arguments, but the draft spec has trailing 'if' and that's a 
sunk-bean-cost (at least by you, the editor -- not by Jason the 
champion-apparent after me).

> As all of these comprehension forms are supported in various other language, it is likely that we could do some data mining and find out occurrence frequencies in real world corpuses .

Jason already did look at other languages for grammar. Surveying code is 
hard since much is firewalled. This is not harmonious anyway. Why are 
you editing anything other than the champion's proposal?

To drop the Harmony process discussion (which I think is critically 
important), what's the complexity argument? Two 'for's and one 'if', at 
end or middle does not matter to the desugaring rules.

/be