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=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,9a0ff0bffdf63657 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,4b06f8f15f01a568 X-Google-Attributes: gid103376,public X-Google-Thread: 1108a1,9a0ff0bffdf63657 X-Google-Attributes: gid1108a1,public X-Google-Thread: f43e6,9a0ff0bffdf63657 X-Google-Attributes: gidf43e6,public From: ell@access.digex.net (Ell) Subject: Re: Software landmines (loops) Date: 1998/09/03 Message-ID: <35eeeb88.5409979@news.erols.com>#1/1 X-Deja-AN: 387329793 Content-Transfer-Encoding: 7bit References: <6rf59b$2ud$1@nnrp1.dejanews.com> <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <904556531.666222@miso.it.uq.edu.au> <6sgror$je8$3@news.indigo.ie> <6sh3qn$9p2$1@hirame.wwa.com> <35ece7ee.1489912@news.erols.com> <35ED7082.1889@hfl.tc.faa.gov> <8SeH1.542$495.132579351@newsreader.digex.net> <35EDAC92.538A@hfl.tc.faa.gov> Content-Type: text/plain; charset=us-ascii X-Complaints-To: abuse@rcn.com X-Trace: winter.news.erols.com 904786559 22437 207.172.60.147 (3 Sep 1998 01:35:59 GMT) Organization: Universe Mime-Version: 1.0 Reply-To: ell@access.digex.net Newsgroups: comp.lang.eiffel,comp.object,comp.software-eng,comp.lang.ada Date: 1998-09-03T00:00:00+00:00 List-Id: Robert Oliver wrote: >Ell wrote: >> >> Robert Oliver wrote: >> : >> : Ell wrote: >> :> >> :> The assertion that "single entry, single exit" is a required, or even >> :> desirable, maxim of structured programming is a myth. >> :> >> :> No one (including RCM) can show that this maxim is in fact a coding >> :> heuristic put forward by any of the founders of the structured >> :> paradigm. [Check past posts in this thread.] >> : Edward Yourdan, in his book Techniques of Program Structure and Design >> : discusses this article: >> >> : C. Bohm and G. Jacopini, "Flow Diagrams, Turing Machines, and Languages >> : with Only two Formation Rules", Communications of the ACM, May 19[6]6, >> : pages 366-371. >> >> : (Is this not *the* foundational article for structured programming?) It was Dijkstra and Dahle who where considered to be the founders of the structured paradigm--especially Dijkstra. See "Art of Literate Programming" by Knuth (CLSC publishers) page 72 >> : "According to Bohm and Jacopini, we need three basic building blocks in >> : order to construct a program: >> >> : 1. A process box. >> : 2. A generalized loop mechanism. >> : 3. A binary-decision mechanism. >> : >> : The process box, shown in Fig. 4.1, may be thought of as a single >> : computational statement (or machine language instruction) *or as any >> : other proper conputational sequence with only one entry and one exit* - >> : such as a subtoutine." "single entry, single exit" is mentioned here, but again it was Dijkstra and Dahle who where considered to be founders of the structured paradigm--especially Dijkstra. >> Where is the proof that this underlays the structured paradigm and an >> assertion that something is "proper" doesn't make it so. What structured >> programming avoided was unstructured flow control. It encouraged the use >> of procedure/routine calls over 'goto'. "single entry and single exit" is an inflexible, inadequate attempt to express the more comprehensive idea of the structured paradigm that we should avoid unstructured flow conrrol. And that wasn't even the only key or main idea of the structured paradigm according to Dijkstra as quoted in "Art of Literate Programming". Dijkstra said the first thing he thought of when "structured programming" was mentioned was *"abstraction"*. >> Along with entry into a procedure >> via a call, the use of 'return' is structured flow control; 'return' can >> only go back to the calling procedure, unlike 'goto' which can branch to a >> label anywhere. >It's interesting that you use the fact that return always returns the >program to a single exit point (the calling procedure) as an argument that this >technique is structured. Indeed, it is at the procedure level. Right, that's the point about avoiding unstructured flow control. >curious. Would you allow goto's if they could not leave the scope of >the procedure? Probably not.) In a post a month ago, I said that I would probably never use 'goto' to go out of a procedure (if that's possible in Basic, or C) Elliott