Allison wrote: > As I was talking to Damian, he came up with a compelling semantic > argument why we would want C<else> blocks to follow, which is a question > that needed to be faced since we rejected C<continue>.
Specifically, the semantic argument with that idea is that CAPITAL blocks attach automatic behaviours to a surrounding scope, but the C<ELSE> behaviour is specifically *not* associated with the surrounding block. Or rather: specifically associated with the *not* of the surrounding scope. Either way, that would make embedded C<ELSE>s seem highly counter-intuitive to me. > 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. 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>. The argument in its favour is simply that it eliminates two not-unusual -- but very annoying -- constructions involving repeated tests. Namely: if (some_test) { while (some_test) { ... } } else { ... } and the more error prone (because it assumes C<some_test> is idempotent): while (some_test) { ... } unless (some_test) { ... } And it replaces them with a very DWIMish alternative: while (some_test) { ... } else { ... } I haven't seen those annoying constructions used as often with C<for> loops, but I imagine they might well occur more frequently in Perl 6, where lazy iterators will make C<for> loops the preferred choice in a far wider range of circumstances. > And something just feels right about C<else> blocks on loops. It fits in > with that Perlish pattern of allowing structures that feel so natural > you wonder why no other language ever allowed them. Yes. That's one of Larry's greatest talents: doing the obvious-in-hindsight. :-) Damian