Block Lambdas: break and continue

[Brendan Eich]

> 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>