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