David L. Nicol wrote:
> "Randal L. Schwartz" wrote:
> >
> > I think we need a distinction between "looping" blocks and
> > "non-looping" blocks. And further, it still makes sense to
> > distinguish "blocks that return values" (like subroutines
> > and map/grep blocks) from either of those. But I'll need
> > further time to process your proposal to see the counter-
> > arguments now.
>
> In the odd parallel universe where most perl 6 flow control
> is handled by the throwing and catching of exceptions, the
> next/last/redo controls are macros for throwing next/last/redo
> exceptions. Loop control structures catch these objects and
> throw them again if they are labeled and the label does not
> match a label the loop control structure recognizes as its
> own.
Sounds like there is a significant consensus that we are still waiting for
some better mechanism to be proposed. Missing that, most would perfer to
leave it alone. Is this correct? Does anyone have an alterative mechanism or
keywords to propose?
Could someone shoot down or prop up the following:
* Subroutines automatically get their name as a label
* Either anonymous code blocks can't short-circuit, or
we use something like "LABEL undef" for the closest
code block
* Allow "code" blocks to catch next/last/redo exceptions
with explicit labels.
* To support both short-circuiting and returning a value
Use: return $value && next LABEL
* We stop calling them loop control statements and start
referring to them as short-circuit statements commonly
used with loop control.
I believe this gets us what we're after with RFC 199: Short-circuiting
C<grep> and C<map> with C<last>.
If there is interest in allowing "loop" and "bare" blocks to C<return>
and/or C<yield>, I'll defer that to another RFC. I'm looking to firm up RFC
199 in as positive a light as possible or failing that withdraw it. I would
like to return to being a lurker ;)
Garrett
