Block Lambdas: break and continue
Brendan Eich
brendan at mozilla.org
Tue Jan 17 00:16:47 PST 2012
> Grant Husbands <mailto:esdiscuss at grant.x43.net>
> January 16, 2012 5:33 PM
> Brendan Eich wrote:
>> 2. Variation on empty label: support "do" as a reserved-identifier label
>>
>> do: arr.forEach {|o|
>> if (...) break;
>> ...
>> }
>
> This seems like a sound way of doing it, indeed (I omitted your first
> one because I prefer this one).
Me too. Had to throw the shorter one out to give it its due.
> It avoids the more egregious syntax
> conflicts and is indicative of being interesting to break/continue.
> Combined with the break-with and continue-with statements, elsewhere
> in this thread, it makes block lambdas better than anonymous functions
> currently are in nearly all cases, along with making it easier to
> replace loops with callback-based iteration.
I will add strawman sections for these extensions to block_lamda_revival
in a bit.
>> To complete the Smalltalk homage we would want this in expressions, and
>> we'd also want do: to take a block-lambda directly, in addition to a
>> CallWithBlockArguments.
>
> Would it call that block-lambda with no arguments?
If the block-lambda takes no arguments, yes. But I'm thinking of
CoffeeScript's do operator, which passes lexical references of the same
name as the block-lambda's parameters:
http://coffeescript.org/#try:list%20%3D%20[1%2C%202%2C%203]%0Afor%20x%20in%20list%0A%20%20do%20%28x%29%20-%3E%0A%20%20%20%20alert%20x
list = [1, 2, 3]
for x in list
do (x) ->
alert x
which for example translates to:
var list, x, _fn, _i, _len;
list = [1, 2, 3];
_fn = function(x) {
return alert(x);
};
for (_i = 0, _len = list.length; _i< _len; _i++) {
x = list[_i];
_fn(x);
}
Apologies for the CoffeeScript if it's not your thing, readers. Here's
the block-lambda with do: version:
let list = [1, 2, 3]
for (let x of list) {
do: { |x|
alert x
}
}
But of course, Harmony for-let-of and for-let-in loops provide a fresh
binding per iteration, so this do: is not needed to capture each
iteration's i value. Let's use old-style for:
let x;
for (x = 1; x < 4; x++) {
do: { |x|
alert x
}
}
Here the single let x binding is prone to being captured with its final
value, 4. The do: calls its block-lambda argument with each x value in
turn, so (e.g.) the block-lambda can safely close over its parameter x
and get each value in [1, 2, 3].
>> This variation is future-hostile to leading-colon as statement- or
>> expression-starting special forms (see<http://wiki.ecmascript.org
>> /doku.php?id=strawman:return_to_label>). I think that this is
>> acceptable but I could be missing something.
>
> I think I'm misreading, but I'm not seeing how "do:" and "return :"
> conflict.
You're right, I was mis-remembering the return-to-label details.
> If break-with and continue-with get specced, they would
> cover the same use case, anyway.
Return-to-label has been fading for a while, it dates from an earlier
lambda proposal era. I agree break/continue-with do the job. I'll talk
to Allen about those a bit tomorrow.
>
> I don't know how the process works, but I'd be happy to assist in the
> creation of additional strawmen to cover these (potentially later)
> additions to block lambdas and other blocks, if consensus is reached.
> I don't want to jump the gun, though.
I thought about new strawmen but still think it better to add do: and
possibly break/continue-with to block-lambda revival to avoid too many
little wiki pages. b/c-with, perhaps, deserve their own page but it's
easy to split if necessary.
Thanks for the offer to help, I may take you up on it yet. And thanks
for the discussion.
/be
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120117/63db464b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120117/63db464b/attachment-0001.jpg>
More information about the es-discuss
mailing list