RE: (RFC 199) Alternative Early-Exit Mechanisms for Blocks?
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 Cgrep and Cmap with Clast. If there is interest in allowing "loop" and "bare" blocks to Creturn and/or Cyield, 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
RE: (RFC 199) Alternative Early-Exit Mechanisms for Blocks?
Garrett Goebel wrote:
Could someone shoot down or prop up the following:
* Subroutines automatically get their name as a label
Ick! Shades of Pascal! Why don't we just replace "return $value"
with "subroutine_name = $value;"!
Seriously, what is the point of
sub func1
{
func2();
}
sub func2
{
last func1;
}
? Imho, it is a BAD THING for functions to know who called them,
and to vary their behavior accordingly.
--
Eric J. Roode, [EMAIL PROTECTED] print scalar reverse sort
Senior Software Engineer'tona ', 'reh', 'ekca', 'lre',
Myxa Corporation'.r', 'h ', 'uj', 'p ', 'ts';
Re: (RFC 199) Alternative Early-Exit Mechanisms for Blocks?
Eric Roode wrote:
sub func1
{
func2();
}
sub func2
{
last func1;
}
? Imho, it is a BAD THING for functions to know who called them,
and to vary their behavior accordingly.
Yes. This is a serious downside to the proposal, even though it was
intended to allow last'ing out of some other kind of nested scope, e.g.
sub func1
{
while(1)
{
last func1;
}
}
But if we keep the block types distinct, as I now believe we should,
one would simply use Creturn there...
--
John Porter
We're building the house of the future together.
Re: (RFC 199) Alternative Early-Exit Mechanisms for Blocks?
Garrett Goebel wrote: * Subroutines automatically get their name as a label My concern here is whether it introduces a problem with Cgoto foo vs. Cgoto foo. If, as you propose, subs do get their name as label, I would like to conflate these two forms. But the semantics of Cgoto foo specifies that @_ is passed as is to the sub entrance. I suppose it would be o.k. to define Cgoto foo identically; just not sure. Any thoughts? -- John Porter We're building the house of the future together.
RE: (RFC 199) Alternative Early-Exit Mechanisms for Blocks?
From: John Porter [mailto:[EMAIL PROTECTED]]
Eric Roode wrote:
sub func1
{
func2();
}
sub func2
{
last func1;
}
? Imho, it is a BAD THING for functions to know who called them,
and to vary their behavior accordingly.
I'm after a next/last/redo mechanism for the subroutine to short-circuit
itself. Besides, you could apply the "bad coding" example to the current
implementation of short-circuiting loops.
OUTER: while (1) {
INNER: while (1) {
func1();
}
}
sub func1 {
last OUTER;
}
My proposal would only allow such "bad coding" when someone does so with an
explicit label, otherwise the status quo is preserved. Let people who
explicitly chose to write bad code to do so. That's their choice. The
default behaviour would remain, and I'll able to short-circuit Cgrep and
Cmap.
Yes. This is a serious downside to the proposal, even though it was
intended to allow last'ing out of some other kind of nested
scope, e.g.
sub func1
{
while(1)
{
last func1;
}
}
But if we keep the block types distinct, as I now believe we should,
one would simply use Creturn there...
This wouldn't help Cgrep. you'd be returning from the context of the code
block... and not Cgrep. I want to short-circuit the built-in, and my own
subroutines that take code blocks.
sub mygrep (@) {
my ($coderef, @list, @results) = @_;
$coderef and push(@results, $_) foreach (@list);
@results;
}
mygrep {$_ == 1 and return $_} (1..1_000_000);
vs.
mygrep {$_ == 1 and return $_ last mygrep} (1..1_000_000);
Garrett
