Comprehensions, Where Art Thou?
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
> (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.
More information about the es-discuss