Re: No Go To's Forever!

[tmoran@bix.com]

>Of course it is different, it does a different sequence of
  Either you disallow "a different sequence of operations",
in which case "Continue := True;" is disallowed, or you allow
irrelevant differences and thus the first of the goto-less
algorithms.  You can't have it both ways.

>Yes, but we are not talking efficiency here,
  Fine.  Sorry you brought it up.

>      J := D'first;
>       while J < D'last loop
>          if D (J) >= D (J + 1) then   -- sorted so far
>             J := J+1;                 -- continue
>          else
>             Swap (D (J), D (J + 1));  -- out of order, move item
>             J := D'first;             -- and start over
>          end if;
>       end loop;
>
> The objection here is again to the duplicated code. You have to
> study this to see that the two assignments to J are identical.
  Huh?  Do you mean the two places it does a "J := D'first;"?
Hardly what I'd call an obscure statement.

>but you must see that it is interesting that your only solutions
>so far involve code duplication to get rid of the goto.
  Yes, gotos allow you to reuse arbitrary segments of code.
I don't think that's necessarily a good thing.

> We always prefer for loops to while loops since they lead to a
> much clearer notion of total correctness.
  A maintenance programmer, on first glance, will probably see
the For 1 ..  N-1 and think "Oh, we're doing something N-1
times", which of course is false.  On second glance he'll notice
the label and realize he needs to study the code further to
figure out the exit condition.  A While both raises a red flag
that this might take a while, and shows directly the exit
condition.  I find the latter clearer.  It's also easier to see
the kind of running time with the While loop than with the two,
nested, with the inner one aborted, loops.

> but I find your formulation really obscures the fact that we have
> two nested loops here.
  Right.  I think it's a single code sequence being iterated until
everything is in order.  It keeps trying to get all the way through
D without discovering anything out of order.  If it fails, it does
a swap and keeps trying.  You think of it as two loops, a For and
an "if ...  goto" loop.

> Replacing a for loop with a while loop with an increment is bad
> in any case.  Replacing it with a while loop that plays games
> with the control variable to obtain the effect of two nested
> loops expressed with one loop at the syntactic level is really
> quite nasty.
  A While loop by nature does not have an incremented "control
variable".  It has a condition.  It is expected that the actions
inside will bring about a state of affairs where that condition
is true.  This may involve incrementing variables, setting them
to D'first, or anything else.

> I am always amazed by the extent to which people are willing to
> go in writing obscure code to avoid gotos; A triumph of form over
> substance :-)
  I don't think either of the goto-less versions was at all
obscure.  I do think the goto version requires more study to
understand what is going on and thus is more obscure.  It also
requires examination of the rest of the code to see if there are
any other gotos to the label.  I prefer the original, shorter,
goto-less version, but if the exact same sequence of operations
is also required, the second version satisfies.