=== 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 ; [email protected]
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
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
