Now, you did say that this is a small program. In a way, so long as your stuff is well-named and well laid out, it almost doesn't matter what way you program this. Heck, your program seems to be simple enough that, if the hooks were there, you could program this in Parrot! (I don't reccomend it, but it could be interesting ...)

Now, you talk about a state machine. If you think about this being a state machine and you don't use CPAN code, you're (probably) reinventing the wheel. The standard distribution for handling state machines in Perl is POE^*. It's a bit of a learning curve, but I would definitely suggest looking there if you consider this a state machine.

As for my feelings on block-driven programming in general ... I guess I would say that it's a neat idea, so long as your codebase remains very very small. This doesn't scale in any meaningful way. *shrugs*

^*CGI::Application can be considered as another state machine distribution, but it is both domain-specific to web applications and doesn't really have built-in support.

If you think about this being a state machine and you don't use CPAN code, you're (probably) reinventing the wheel. The standard distribution for handling state machines in Perl is POE*.

But it's big and clunky and doesn't read like normal Perl code. For a simple FSM, there is absolutely no reason to use POE, as POE tends to make your app into a "POE application", transmogrifing it. Reinventing your own will result in something a lot more concise. POE is cool, but it is *much* more than just a state machine, and I really doubt everytime someone recommends it that they have actually used it for that purpose. Implementation of basic state machines WITHOUT goto's is basic CS1, and those that use goto's to do this are doing really shoddy programming.

Gotos (and their P.C. cousins "abused exceptions") must die. They lead to poorly maintainable code that is both hard to read and trace.

A simple state machine without gotos (pardon the syntax errors):

$state = 'foo'; 
$running = 1;
while($running) {
   if ($state eq 'foo') {
        # do stuff
        $nextstate = 'bar';
   }
   elsif ($state eq 'bar') {
        # do stuff 
        $nextstate = 'baz';
   }
   elsif ($state eq 'baz') {
        # do stuff
        $running = 0;
   }
   $state = $nextstate;
}
[download]

Gotos (and their P.C. cousins "abused exceptions") must die. They lead to poorly maintainable code that is both hard to read and trace.

There's no reason they lead to poorly maintainable code. They only lead to poorly maintainable code if they are misused. But it isn't too difficult to write spaghetti code using OO and no gotos - but that isn't a reason to say that OO must die. Perhaps you should read Knuth's paper "Structured programming with Go Tos", where he shows that if used appropriately, use of gotos is fine.

Quoting from my own work, part of a C program I modified last week:

  __close1:
    if (close (soc) < 0) {
        if (errno == EINTR) {
            goto __close1;
        }
        perror ("close");
        exit (1);
    }
[download]

I don't think this is less maintainable than writing a loop.

Abigail

Gotos...must die.

But Dijkstra died instead, while goto lives on. Sad.

Which pro's and con's do you see for each approach?

Abigail

You'll see the downsides of that approach as soon as you reach blocks F, G and H, which do the "same as .. with ..", which clearly looks like you want to have block C as a function, taking cartein arguments, being called from certain points of your main program with different parameters. I mean, you could write your block-based program and then refactor out all the redundant stuff that you find. Personally, i'd try to find the obvious things before and not write block-stuff at all.

Perhaps writing a subroutine for each block may help. While you write each sub, try to make it as flexible as possible. Finally you only need a main script, keeping the main program's state variables and calling the subs accordng to the overall logic.

You might want to think of an OO model for your data, not only refactoring to subs, but to classes and methods. The main program does then not just keep state "variables", but objects, which you might want to reuse somehwere else...

I'm sure you won't need named blocks in the end, only "if", "while" and subroutines. No redo, but tail recursion.

I agree with your post up until the point about tail recursion. Tail recursion is *easily* eliminated by reducing the recursion to a simple loop. This is much friendlier on your stack, and much more efficient! Other forms of recursion are harder to eliminate, but the refactoring of tail recursion is well known.

That being said, tail recursion often serves as as decent way to design an algorithm originally, but it should be eliminated when you get the chance.

In his case, assume the program is a "C" program implemented as a state machine that will run for years. Tail recursion would chew up a tremendous amount of stack and lead to program termination. Refactored as a simple while loop, the program would run forever.

This is one (not so rare) example where the reality of how a computer works oversteps the theory of basic "computer science". What appears to be logically equivalent is not once you put it on real hardware.

edit: darn, it looks like I'm turning into a CS professor now... run away! run away!

This is one (not so rare) example where the reality of how a computer works oversteps the theory of basic "computer science". What appears to be logically equivalent is not once you put it on real hardware.

What has "real hardware" to do with it? All you need is a compiler that's able to detect tail recursion, and eliminate it, instead of putting the burden on the programmer. Yes, such compilers exist. Ironically, they are more common in environments that are more concerned with the 'theory of basic "computer science"' than in environments that use 'real hardware'.

Abigail

EDIT_MAP: {
  attempt_edit($map);
  redo EDIT_MAP  unless can_parse($map);
  redo EDIT_MAP  unless user_confirms($map);
  attempt_edit($reverse_map);
  redo EDIT_MAP  unless can_parse($reverse_map);
  redo EDIT_MAP  unless user_confirms($reverse_map);
}
commit_edit($map, $reverse_map);
[download]