On May 10, 2013, at 11:36 AM, Brendan Eich wrote:

> Jason Orendorff wrote:
>> On Thu, May 9, 2013 at 11:42 PM, Mike Stay <metaweta at gmail.com <mailto:metaweta at gmail.com>> 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.
> 
> 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.
> 
>> 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 http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax is an error. Perhaps we should change this to match the keywords. Allen?

Oy yeah, look at that... I don't like these sorts of static semantics restrictions on expression elements.   PrimaryExpression does't have the context to make the determination and it's a pain to restrict it at the level of ArrowFunction (although I do something like that for yield).  I think this spec. complications reflect a user perspective that it is a nanny restriction.  We're basically saying: you might not understand the semantics of arguments within an arrow (whatever we decided it was) so we won't let you use it at all.

Personally, I prefer Jason's perspective.  Arrows don't have their own arguments object and "arguments" just lexically binds.

Allen

On May 10, 2013, at 11:36 AM, Brendan Eich wrote:

> 'arguments' per http://wiki.ecmascript.org/doku.php?id=harmony:arrow_function_syntax is an error. Perhaps we should change this to match the keywords. Allen?

Oy yeah, look at that... I don't like these sorts of static semantics restrictions on expression elements.   PrimaryExpression does't have the context to make the determination and it's a pain to restrict it at the level of ArrowFunction (although I do something like that for `yield`).  I think this spec. complications reflect a user perspective that it is a nanny restriction.  We're basically saying: you might not understand the semantics of arguments within an arrow (whatever we decided it was) so we won't let you use it at all.

Personally, I prefer Jason's perspective.  Arrows don't have their own arguments object and `arguments` just lexically binds.

Allen