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
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
