Block Lambdas: break and continue

[Grant Husbands]

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.