Block Lambdas: break and continue
Grant Husbands
esdiscuss at grant.x43.net
Sat Jan 14 05:35:33 PST 2012
I should have been clearer in my original message; I'll avoid
mentioning Ruby directly, again, as it misdirects conversation.
Though I have no strong opinion on block-lambdas in javascript, I will
try to restate my original position, for clarity:
Block lambdas, as currently described in the proposal and in the
community, have 'forEach' and similar as driving examples; I believe
that a typical programmer would expect break or continue to directly
affect that loop, and that that behaviour may be desirable.
Brendan Eich wrote:
> "Intuitive" depends on intuition, which is not well-defined.
True, but I do believe in intuition without the bias of a source
language. I understand that intuition can vary, so I might be aiming
for 'average practitioner's intuition' or such.
> Do you mean a Rubyist might expect different behavior for break?
I believe that the typical programmer, given the briefest exposure to
block lambdas, would believe that 'continue' would behave the same way
for a block-lambda-based loop as it does for any other loop.
> Wait, why do you think break and continue without label operands
> do anything other than break from the nearest enclosing loop
What I meant was that, in the typical examples, 'forEach' is the
nearest enclosing loop, and continue and break apparently bypass it.
> The Array.prototype.forEach method's internal implementation is
> its business, and a break instead of the return would be a static
> error in this example. It would not be a dynamic throw-like
> construct that is caught by forEach's implementation.
Indeed, the way break would need to work could be a show-stopper for
my proposed alteration, but I was trying to avoid implementation
detail. My intent was to raise the divergence from (in my opinion)
intuitive behaviour in the case of block-lambda-based loops.
Regards,
Grant Husbands.
More information about the es-discuss
mailing list