Re: No Go To's Forever!

[Robert Dewar <robert_dewar@my-deja.com>]

In article <tNwC4.964$q41.1034@news.pacbell.net>,
  tmoran@bix.com wrote:
> >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.

Actually you can, but this is very standard stuff in any
formal algorithms book, not worth repeating here.
>
> >Yes, but we are not talking efficiency here,
>   Fine.  Sorry you brought it up.

No, it was not just a matter of efficiency

>
> >      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.

You are missing the conceptual point here entirely. I can only
recommend rereading my previous posts.

> >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.

Well if you don't understand why obscuring the two loop
structure is a problem, then I guess there is no explaining
it any further.

But there really is a very fundamental point here. If you want
to study it further, try generating the full denotational
semantics and in fact try generating the full proof conditions.
That will make things clearer I think.


Sent via Deja.com http://www.deja.com/
Before you buy.