Re: Block Lambdas: break and continue

[Brendan Eich]

Herby Vojčík January 14, 2012 1:46 PM === Brendan Eich wrote === This doesn't address Herby's TCP-violating wish for a non-return that completes the block-lambda's control flow normally with a value (the message to which I was replying). But you're right that it wouldn't violate TCP either if we support it the same in a block statement as in a block-lambda downward funarg. === No. it wasn't my primary wish to have a local return. I understand, but (as you seem to concede below) if the TCP violation this introduces is enough to kill it, I thought I'd argue against it on that basis. Sorry for seeming to miss your larger point -- I am following it closely too ;-). I wanted to make break and/or continue _semantics_ for lambda-block-loop-like-constructs. Understood. So since local return is already used for 'continue' in forEach, I just generalized the syntax continue |expr|; (note the | bars, they are part of the syntax) Oh! I didn't know that. Often we (certainly I do this, others too) use bars in such sketches as meta not concrete syntax. Thanks for clarifying. Anyway, as others have written, this seems an abuse of 'continue'. Also, you cannot avoid the exception-like effect if this is to propagate to the forEach's internal loop. There's no loop visible to the spec or an implementation's compiler. So this really is a throwing form. Again I do not see how it can be "exception-less". to do the local return, thereby functioning as a continue statement. (It would be convenient to have local return, but not the local return itself was the goal). Local return violates TCP, so we should debate that vs. convenience if you like. Sorry if that is not something you want to debate, but I think you raised the issue directly and should respond. You are true it breaks TCP. (It could be done so that it does not by generalizing the syntax so it works in syntax-loop construct as well with "end loop body with expr as the completion value" semantics; it's only btw, it's too crazy to be considered, probably) So it cannot be used. :-/ Agreed. But let's debate the exception-less claim anyway, to each mutual understanding. By "this is de-facto continue" I was thinking more in higher semantic level - continue as in "continue past this block", which in loops means "to the next iteration" but beyond loops it may mean anything that is going to happen after block completes. The problem is the loop in Array forEach, or any such dynamically dispatched caller of a block-lambda that is acting as a mapfun or iterator, is hidden from static analysis. So such a de-facto continue (I see what you mean now; I mentioned early return from forEach callback as continue myself) must throw. It cannot be exception-free. Sorry to harp on this, I wonder if one of us is still misunderstanding something. Also, break is hard to do similar way, because I count out (automatically set up) exceptions (I still live in the impression they are, performance-wise, expensive). Yes. It seems to be possible to have "break |expr| label;" syntax working: if the function calling the lambda-block is labeled, it should be possible to just make it return the expr, but it is clumsy (and there is no label-less version). This reminds me of dherman's escape continuation proposal: http://wiki.ecmascript.org/doku.php?id=strawman:return_to_label We did not promote it from Strawman to Harmony status. Overall, I am a bit optimistic, since (if I am not mistaken) lambda-blocks only work inside its scope (as Self blocks, not as Smalltalk blocks), which saves a lot of complications. Block-lambdas can escape via the heap and be called later (so-called async. callbacks). That is not a problem if they do not use return, break, or continue. The TCP conformance for |this| is still a win. The completion implicit return can be a win too. /be Herby [Finally trimming overcites!] /be

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