Introduction, comprehensions beyond arrays

Mike Stay metaweta at
Fri May 10 11:50:07 PDT 2013

On Fri, May 10, 2013 at 12:36 PM, Brendan Eich <brendan at> wrote:
> Jason Orendorff wrote:
>> On Thu, May 9, 2013 at 11:42 PM, Mike Stay <metaweta at
>> <mailto:metaweta at>> wrote:
>>     In Scala, this is desugared into
>>       expr1.flatMap(x =>
>>         expr2(x).flatMap(y => ...
>>           exprN(x, y, ...).map(z =>
>>             result(x, y, ..., z)
>>           )
>>         )
>>       )
>> Currently comprehensions use the same protocol as for-of statements,
>> namely iterators. I think we definitely want them to use the same protocol.
>> .map() is appealing, but to work with for-of statements, it would have to
>> support break, continue, and early return, either using exceptions (like
>> Scala's Breaks) or something new. Part of the appeal of the iterator
>> protocol is that it doesn't complicate break/continue/return.
> Agreed. JS ain't Scala.

I wouldn't want it to be!  And I agree that it makes sense for the
array comprehensions to match the for-of semantics.

> Note for Mike Stay, in case it helps a bit (just syntax): we agreed to use
> LTR order, so:
> [for (x of expr1) for (y of expr2(x)) result(x, y)]
> to shorten your example a bit.

OK, thanks.  I suppose that with the arrow-functions, the boilerplate
load drops tremendously.  Is the ES6 spec too far along to introduce
some other construct that would desugar to the above, or is there
still time to create a proposal?

>> Separately, for the list: are arrow-functions lexically transparent to
>> super and arguments? I hope so! For this kind of desugaring, if nothing
>> else.
> 'super' like 'this' is lexical -- the outer function's same-named keyword
> meaning.
> 'arguments' per
> is an
> error. Perhaps we should change this to match the keywords. Allen?
> /be

Mike Stay - metaweta at

More information about the es-discuss mailing list