On Sat, Apr 27, 2002 at 10:53:09PM +1000, Damian Conway wrote:
> Allison wrote:
>
> > And the discussion of scope led to (what I think is) an interesting
> > tidbit on NAMED blocks...
>
> Which I presume was that the proposed usage:
>
> while $result.get_next() -> $next {
> # do something with $next...
> ELSE {
> if $next eq "xyz572" {
> print "We defined this value, $next, as false for obscure purposes.";
> print "No loop was executed. Just wanted to let you know.";
> }
> }
> }
>
> would actually be a (very subtle and nasty) bug!
>
> The construct:
>
> -> $next {...}
>
> is, of course, an anonymous subroutine declaration. Hence C<$next> is
> a parameter, the binding of which only occurs when the subroutine is
> invoked (i.e. on each iteration). However, if the C<while> condition
> fails, the subroutine *isn't* invoked, so C<$next> isn't bound, so the
> nested C<ELSE> block (even if it were fired off separately) wouldn't
> work as expected.
Yes, that's what I meant. You see, I had visualized a slightly different
(and more convoluted) order of events in which the parameter was bound
anyway and the NAMED blocks were set up as "triggers" associated with
the block early enough in the complilation process that they would be
available at run-time when a "skipping this block" event occurred. But
this is much cleaner and more efficient in execution. And if you really
need a meta way of knowing *why* the .get_next() method returned a false
value, throw an exception and catch it. Of course, you can't catch it in
the C<else> block. You'll have to catch it in a block wrapped around the
whole C<while...else> construct. But the times when you need that level
of detail will probably be far less frequent than the times when you
just want to know the loop didn't execute.
> This leads me to conclude that a normal (trailing, un-nested) C<else>
> is a much more reasonable construct for a C<while> -- and at least
> arguable for a C<for>.
And C<loop>, I hope.
Allison
