Introduction, comprehensions beyond arrays
allen at wirfs-brock.com
Fri May 10 11:49:27 PDT 2013
On May 10, 2013, at 8:48 AM, Jason Orendorff wrote:
> On Thu, May 9, 2013 at 11:42 PM, Mike Stay <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.
We previously explored having lambdas expressions that included support abnormal exits, including method level returns. I even did most of the spec. work that would be needed to define them. But the ultimate consensus was formed around arrow functions without such control escapes.
> 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 is lexically resolved through the defining method so, just like this, it isn't rebound within an arrow function. Follow the spec. logic starting in 11.2.4.
I see that I have a TODO note in 10.5.3 that says "don't create an arguments binding for arrow functions". However, I'm not sure that we actually had consensus on that point. I'm with you on in thinking that arrows shouldn't rebind arguments but I think there may have been some push back on that.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss