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.3 required=5.0 tests=BAYES_00, 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 From: "John G. Volan" Subject: Re: Mid-Loop 'Until' Proposal [was: Software landmines (loops)] Date: 1998/09/06 Message-ID: <35F35AF8.894B3E10@sprintmail.com> X-Deja-AN: 388577736 Content-Transfer-Encoding: 7bit References: <902934874.2099.0.nnrp-10.c246a717@news.demon.co.uk> <6r1glm$bvh$1@nnrp1.dejanews.com> <6r9f8h$jtm$1@nnrp1.dejanews.com> <6renh8$ga7$1@nnrp1.dejanews.com> <6rf59b$2ud$1@nnrp1.dejanews.com> <6rfra4$rul$1@nnrp1.dejanews.com> <35DBDD24.D003404D@calfp.co.uk> <6sbuod$fra$1@hirame.wwa.com> <35f51e53.48044143@ <904556531.666222@miso.it.uq.edu.au> <6sgror$je8$3@news.indigo.ie> <6sh3qn$9p2$1@hirame.wwa.com> <6simjo$jnh$1@hirame.wwa.com> <6sjk3p$4tc$1@hirame.wwa.com> <9hdH1.464$08.176350@news.giganews.com> <35EF3DCD.CC060E37@ac3i.dseg.ti.com> <35F2E055.6922B7EC@earthlink.net> X-Posted-Path-Was: not-for-mail Followup-To: comp.lang.eiffel Content-Type: text/plain; charset=us-ascii X-ELN-Date: Sun Sep 6 21:04:11 1998 Organization: EarthLink Network, Inc. Mime-Version: 1.0 Reply-To: johnvolan@sprintmail.com Newsgroups: comp.lang.eiffel,comp.lang.ada Date: 1998-09-06T00:00:00+00:00 List-Id: [cross-posted to comp.lang.ada because of Ada comparison, but followups trimmed to comp.lang.eiffel only] Charles Hixson wrote: > > If this is to be done, then I would advocate using "Exit When ..." > instead of "Until ...", as > 1) it more accurately captures the feel of what is to be done and > 2) it conforms to Ada95 usage for the same construct > On The Other Hand: > I'm fairly sure that Bertrand Meyer states somewhere that he considered > this construct and why he decided against it (I just don't know where > "somewhere" is). > I think that it would be a very useful construct, but without > remembering the rationale that was originally given for doing it the > other way, I would hesitate to advocate it. I would advocate against introducing an "exit when..." into Eiffel's loop construct, for both syntactic and semantic reasons. Syntactically speaking, why use two keywords ("exit when") when one keyword ("until") will do the job equally well? Why introduce another reserved word ("exit") into the language, for no good reason? Furthermore, a mid-body or end-body "until" clause would be just that: a _clause_, an intrinsic part of the structure of the loop construct itself, on par with the top-of-body "until" clause, or the "from" clause, or the "invariant" clause. On the other hand, if we truly follow Ada's lead, an "exit when" would be a kind of _statement_, just one of many statements nested within the body of the loop. That distinction is evident in the difference in indentation styles used: -- Eiffel.increment :-) -- Ada from loop loop io.readint Get (N); until io.lastint = 0 exit when N = 0; else process (io.lastint) Process (N); end end loop; As you can see, the "until" and "else" keywords are indented at the same level as the rest of the keywords in the "skeleton" of the loop; whereas the "exit when" statement is indented at the same level as the other statements nested in the body. This difference between a clause and a statement is a crucial distinction, one which, I believe, goes to the heart of whether a construct is "structured" or not. Eiffel's loop statement (even with the proposed extension) is "structured", because it is a _modular_ construct: 1. Its control-flow properties are completely determined at a single level, and are all clearly evident at that level. 2. All the Compounds (sequences of Statement) nested in the various clauses in the loop can be treated as single-entry/single-exit modules -- "black boxes." Their own internal control-flows have no ultimate affect on the overall control-flow defined by the loop as a whole. Each such compound could, in principle, be replaced by a single procedure call, and the loop would still behave the same. These properties allow correctness analysis to be done _recursively_: Once you establish the correctness of the nested Compounds, and determine their preconditions and postconditions, you can essentially ignore their internal details at that point, and proceed to analyze the loop itself at its own level, looking at its invariants, postconditions, and so forth. But an "exit when" statement, or any similar statement such as "break" or "continue", interferes with this modularity, because it modifies the control flow properties of the loop from deep within it. If a nested Compound contains one of these beasts, then it is no longer a SE/SE "black box" that you can equate with a procedure call. It now has two ways to exit: It can execute all the statements in its sequence, or it can trigger its exit statement and jump to the end of the loop. This makes it impossible (or at least more difficult) to do correctness analysis in a recursive way. This effect can be deeply infectious, because an "exit when" statement could be nested at any depth: loop ----- ... ... ; \ if Condition_A then \ ... statements ... ; \ if Condition_B then \ ... statements ... \ exit when Condition_C; \ ... statements ... \ else \ this Compound has ... statements ... > 3 ways to exit, if Condition_D then / from 3 (or 4?) different ... statements ... / nesting levels exit when Condition_E; / ... statements ... / end if; / ... statements ... / end if; / end if; / ... ---- end loop; What, exactly, is the postcondition on this loop? Which groups of statements could be consolidated as SE/SE "black boxes" for purposes of correctness analysis? Let's not go there. :-) -- indexing description: "Signatures for John G. Volan" self_plug: "Ex Ada guru", "Java 1.1 Certified", "Eiffelist wannabe" two_cents: "Java would be even cooler with Eiffel's assertions/DBC, % %generics, true MI, feature adaptation, uniform access, % %selective export, expanded types, etc., etc..." class JOHN_VOLAN_SIGNATURE inherit SIGNATURE invariant disclaimer: not (opinion implies employer.opinion) end -- class JOHN_VOLAN_SIGNATURE