From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: * X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,14f7200925acb579 X-Google-Attributes: gid103376,public From: Robert Dewar Subject: Re: No Go To's Forever! Date: 2000/03/24 Message-ID: <8berdq$j2p$1@nnrp1.deja.com>#1/1 X-Deja-AN: 601609528 References: <8bdbof$t19$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x41.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Fri Mar 24 04:37:16 2000 GMT X-MyDeja-Info: XMYDJUIDrobert_dewar Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; I) Date: 2000-03-24T00:00:00+00:00 List-Id: In article , 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.