Bare Blocks And Labels Was: Re^4: Re Execute Lines of Code ("loops")

I agree with the view that next, last, and redo can make code less readable.

A bare block is, in Perl, a loop that falls through after its first pass. This is by language definition and so it should not be discounted in one's mental model of the language.

I think of a bare block primarily as a looping construct. If a block follows the normal pattern of a closure, I expect it to be just a scoping construct. I haven't found the worth of a bare block to put over or under a package:

{
    package Yme;
    code;
}
[download]

and

package Ynot;
{
   code;
}
[download]

I am not enamoured of labels in Perl and tend to avoid them. Labels should be used only when necessary to choose a loop or to clarify a mess which cannot be cleaned up.

Labels smell. They all fall into one namespace, cannot be declared, and are slimey to name. Labels and goto behavior seem inadequately defined in the docs. Many people expect a goto LABEL to go to the textually nearest label, with more active use, this model breaks down because the actual behaviour is more dynamic.

Pop quiz:

In the below code, what is the output?

And again, with the marked lines uncommented?

sub lup { "LOOP" }
sub say { print @_, $/; sleep 1; }

LOOP:
    say 0;

#sub mysub {    # uncomment
  INNER:
 {
   say 1;
   goto +lup();
   say 2;
  }
  LOOP: {
    say 3;
    goto LOOP;

  LOOP:
    say 2;
  }
#}          ### uncomment

#mysub();    ### uncomment
[download]

Be well,
rir

Comment on Bare Blocks And Labels Was: Re^4: Re Execute Lines of Code ("loops") Select or Download Code

Replies are listed 'Best First'.
Re: Bare Blocks And Labels (Re^4: "loops") by tye (Sage) on Jan 29, 2008 at 20:50 UTC
A bare block is, in Perl, a loop that falls through after its first pass. It is a loop that doesn't loop. If you prefer, you can update my statements to be that when I see a bare block, I don't expect it to loop. The vast majority of the time I am correct (or, all of the time I am correct since what next, last, and redo do inside a bare block is a bit of a stretch to call looping anyway -- redo comes close but it doesn't make the whole "loop" loop so even through there is some looping going on there, it is going on in a subset of the block so it isn't the block that is looping). This is by language definition and so it should not be discounted in one's mental model of the language. If I see hoof prints, I don't expect that they are from a zebra. That doesn't mean that I'm not aware of zebras nor that I discount the possiblity of zebras especially when I see black and white stripes, especially when I'm at a zoo. But I certainly discount zebras when walking around away from the zoo and away from Africa, even when I see hoof prints. And I feel completely justified in doing so. When I see a lone open brace, I absolutely assume that it isn't going to loop rather then jumping to look for things that would make it (not-quite) loop nor even wondering whether or not it was meant as the start of some (not-quite) "loop". Revising that assumption in the rare cases is less work in the aggregate. By the language definition, `do { ... } while( ... );` is not a loop, it is just a non-loop that loops. These two unfortunate language definitions have been corrected in the next design. So I am in good company in finding fault with them. I'm not even convinced that the "language" defines loops that way. Surely the parts that deal with next, last, and redo define loops that way. They also define `... while ...;` as a non-loop in that regard. But I doubt you are told to narrow the scope of a lexical variable by enclosing it in a loop. But even if the language defines "loops" as things in which next, last, and redo work, I find that a pretty poor choice of terminology and will stick to defining "loops" as things that "loop". This leaves me without a term for "things in which next, last, and redo work". I'm not bothered as '`"loop"`' (the word in scare quotes) works for me. As to labels, I've never had much use for them at all and certainly don't encourage using them prolifically. The proposed use of labels sounds intriguing but I haven't put it to use, much less used it enough to have a confident proclamation as to how good of an idea it is in practice. But none of your valid complaints about labels actually apply to the proposed use of labels. You could use such horrid lable choices as "LOOP" or "LABEL" and never change the behavior of the code by adding the "clarifying" labels. If you label every loop that contains a next/last/redo with the exact same "LOOP:" label, and change every `next;` to `next LOOP;`, Perl will find the correct label (but the human reading the code might not). So even the slightest reduction of ambiguity offered by labels "LOOP1:" and "LOOP2:" would improve clarity. But there is the risk of mistyping a label. If you mistype a label and happen to match a label used in a loop from the current dynamic scope, then you'll likely only get a warning to help you realize your mistake. Well, unless you have unit tests which should excercise the code w/o surrounding loops and detect the error for you quite early. So I encourage a healthy suspicion of labels. If you make the use of next/last/redo quite rare, then the addition of labels to such uses might be a good idea. I can see value in such a practice and still have not seen much to discourage such a practice. Note that I'd use labels more like "FILE", "LINE", "TOKEN", whatever the loop is iterating over. I'd never use "LOOP" any more than I'd use "LABEL". - tye	[reply] [d/l] [select]
Re: Bare Blocks And Labels Was: Re^4: Re Execute Lines of Code ("loops") by ysth (Canon) on Jan 30, 2008 at 09:18 UTC
Your pop quiz could just have a bare block where you have sub mysub { ... } (and no mysub() call). `{ print "endlessly\n" } continue { sleep 1 and redo }` -- Online Fortune Cookie Search	[reply] [d/l]