Comprehensions, Where Art Thou?

Brendan Eich brendan at mozilla.org
Mon Aug 11 13:12:22 PDT 2014


Tab Atkins Jr. wrote:
> Okay, it's still a little bit harder to read, due to the .concat() 
> calls and their attendant additional parens, and the parens around the 
> for-of bodies, but it's not *terribly* worse.  It's still bad enough 
> that I don't know if I'd write it.

Strings are iterable in ES6, which helps. The stuff you're citing is of 
the sort where "it wasn't the last paren I ate that made me fat" and 
"every little bit helps". That's why when I first proposed for ES4 and 
implemented comprehensions in JS1.7-8, I used paren-free head syntax. 
But paren-free has issues with comp-expr at end (more on this below).

Can't help lack of + on arrays until we get operators sorted out (ES7, 
progress made at last f2f). So JS will suffer the .concat calls in the 
meanwhile.


> (Man, now that I've looked at these for a bit, I really see the logic 
> of Python putting the value *before* the for.  It gives you an 
> examplar value of what the array will look like, right up front, 
> before sliding in the "and here's how you make the rest of them!" 
> indicator.  It also means that all three constructions have the 
> cross() call, the important part, lined up in front so you can see the 
> parallel structure more easily.  This really helps me comprehend the 
> code, no pun intended.)

Me too, but I lost that battle a while ago. The "LTR" forces prevailed 
and I don't see much point in reopening, except to compare unbiased 
Python sources such as Peter's solver to various ports. The "RTL" 
comprehension style is Math-y and again works best with short 
quantifiers and qualifiers. Comprehensions should be one-liners, with 
rare exceptions such as unitlist's initialiser.

/be


More information about the es-discuss mailing list