Block Lambdas: break and continue

François REMY fremycompany_pub at yahoo.fr
Sat Jan 14 12:42:28 PST 2012


Does it really make sense? If your goal is to return a value, using 
'continue' is a lie. You may for exemple write "continue false" to break a 
loop or return from an event. It has nothing to do with a continue 
statement. A continue statement should be the complementary part of a break 
statement. If what you want is a way to return a value, you need a 'return' 
statment. Since 'return' returns from callee function, you need a modifier.

    // exemple of bad code using continue 'value'

    function someFunc(iterator) {
        document.addEventListener({|e|
            if (e.blablablabla) {
                continue false;
            }
        });
    }

My random thoughts would be:

    return with false;
    let return = false;
    ...

Another option is a specific way to break/continue from a code pattern. What 
about 'throw break' / 'throw continue'?

François



-----Message d'origine----- 
From: Herby Vojčík
Sent: Saturday, January 14, 2012 7:42 PM
To: David Herman ; Axel Rauschmayer
Cc: Brendan Eich ; es-discuss at mozilla.org
Subject: Re: Block Lambdas: break and continue

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

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



More information about the es-discuss mailing list