Block Lambdas: break and continue

Herby Vojčík herby at mailbox.sk
Sat Jan 14 10:42:00 PST 2012


=== David Herman wrote ===
This *may* not violate TCP (I'm not quite sure), but I'm not enthusiastic 
about the idea. The semantics is significantly more complicated, and it 
requires you to understand whether a higher-order function like forEach is 
catching these exceptions or not. So it becomes an additional part of the 
API of a function. If someone doesn't document what they do with 
BreakException and ContinueException, then writing callbacks you won't 
actually be able to predict what `break` and `continue` will do.
===

What about the exception-less suggestion I put in? It should work in any 
loop construct with lambda-block, even if you must know a little about the 
loop implementation itself. That is, to be able to put:

    continue |expression|;

as a statement in lambda block which instructs the lambda-block itself (not 
the outer function) to return the expression? This is the de-facto continue 
semantics (lambda-block, do return a value and the enclosing loop will 
continue to the next iteration (possibly stopping the loop if it chooses not 
to have more iterations)). It is not possible to enforce break in the same 
manner, but for continue, it is possible.

Herby

-----Pôvodná správa----- 
From: David Herman
Sent: Saturday, January 14, 2012 6:12 PM
To: Axel Rauschmayer
Cc: Brendan Eich ; es-discuss at mozilla.org
Subject: Re: Block Lambdas: break and continue

On Jan 13, 2012, at 9:04 PM, Axel Rauschmayer wrote:

> I think it’s a valid concern. The idea is: If I can implement my own loops 
> (the nice-looking paren-free syntax feeds that illusion!) then I also want 
> those loops to have break and continue. You could statically determine 
> what construct, say, a break applies to and either throw a BreakException 
> (if it applies to a lambda) or TCP-break (if it applies to an enclosing 
> non-lambda loop). In the examples below, when I see a continue, I look for 
> the innermost enclosing loop braces and the ones belong to list[i].forEach 
> are definitely candidates.

If I understand your suggestion, you're proposing that non-local break and 
continue should be exposed as standard exceptions, and then implementors of 
loop-like abstractions could choose to catch them. E.g. you could implement 
forEach as:

    Array.prototype.forEach = function(f) {
        for (let i = 0, n = this.length; i < n; i++) {
            try {
                f.call(this, this[i], i);
            } catch (e) {
                if (e instanceof BreakException)
                    break;
                else if (e instanceof ContinueException)
                    continue;
                else
                    throw e;
            }
        }
    };

Whereas a function that does *not* want to expose whether it's using loops 
would simply do nothing with BreakException and ContinueException, and they 
would propagate out and you'd get the lexical scoping semantics. Meanwhile, 
break/continue with an explicit target would never be catch-able.

Did I understand your suggestion correctly?

This *may* not violate TCP (I'm not quite sure), but I'm not enthusiastic 
about the idea. The semantics is significantly more complicated, and it 
requires you to understand whether a higher-order function like forEach is 
catching these exceptions or not. So it becomes an additional part of the 
API of a function. If someone doesn't document what they do with 
BreakException and ContinueException, then writing callbacks you won't 
actually be able to predict what `break` and `continue` will do.

Dave

_______________________________________________
es-discuss mailing list
es-discuss at mozilla.org
https://mail.mozilla.org/listinfo/es-discuss 



More information about the es-discuss mailing list