Block Lambdas: break and continue

Herby Vojčík herby at mailbox.sk
Sun Jan 15 04:56:02 PST 2012


it works as continue in forEach and every, but not in some

Sorry, mistake: it works as continue in forEach and some, but not in every

-----Pôvodná správa----- 
From: Herby Vojčík
Sent: Sunday, January 15, 2012 1:13 PM
To: Grant Husbands ; Brendan Eich
Cc: es-discuss at mozilla.org
Subject: Re: Block Lambdas: break and continue

Hi,

your 'for call {|| ...}' is great and simple solution for (unlabeled) break,
but it is not so for continue. For either continue could have the redesigned
meaning I sketched out in my last post, but then you need expression to
specify; or you want the legacy meaning of "go on with the next step" which
you can't achieve by simply skipping to end of the block and returning
undefined - it works as continue in forEach and every, but not in some, for
example.

Herby

-----Pôvodná správa----- 
From: Grant Husbands
Sent: Sunday, January 15, 2012 12:51 PM
To: Brendan Eich
Cc: es-discuss at mozilla.org
Subject: Re: Block Lambdas: break and continue

Brendan Eich wrote:
> More when I reply to Axel in a bit.

I think there may have been a misunderstanding. My proposed solution
amounts to syntactic sugar over the existing strawman and makes
break/continue work intuitively with loopy block lambdas, and your
reply to Axel appears to be against an exception-based version, but
you seem to have (implicitly) tied them together.

> Of course we want to uphold TCP, which constrains the design. What works
> here must work in a regular block statement as body of such a loopish
> structure.

Well, the LCP (Loop Correspondence Principle :) is maintained. So, you
can change your loop construct from:
for (var i=0; i<arr.length; ++i) {
  var o = arr[i];
  if (...) break;
}

To this:
for arr.ForEach { |o|
  if (...) break;
}

And it still works, without needing to throw exceptions or alter the
existing library code. I believe TCP to be maintained everywhere it
might apply, not least because there's a syntactic opt-in, but I may
have missed what you're pointing out.

If the syntax conflicts disastrously with paren-free, then a suitable
nearby syntax could be chosen. I'm not attached to the syntax; I'm
simply offering an implementation strategy that's minimal, matches
most requirements and doesn't appear to break any of the imposed
rules; I don't know the other strawman proposals well enough to avoid
conflicting syntax. It's a boolean toggle, though, so it should be
easy to find a suitable syntax.

Regards,
Grant Husbands.
_______________________________________________
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