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.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: fac41,2c6139ce13be9980 X-Google-Attributes: gidfac41,public X-Google-Thread: 103376,3d3f20d31be1c33a X-Google-Attributes: gid103376,public X-Google-Thread: f43e6,2c6139ce13be9980 X-Google-Attributes: gidf43e6,public X-Google-Thread: 1108a1,2c6139ce13be9980 X-Google-Attributes: gid1108a1,public From: doylep@ecf.toronto.edu (Patrick Doyle) Subject: Re: Interface/Implementation (was Re: Design by Contract) Date: 1997/09/06 Message-ID: X-Deja-AN: 270162119 Sender: news@ecf.toronto.edu (News Administrator) References: <340C85CE.6F42@link.com> X-Nntp-Posting-Host: skule.ecf Organization: University of Toronto, Engineering Computing Facility Newsgroups: comp.object,comp.software-eng,comp.lang.ada,comp.lang.eiffel Date: 1997-09-06T00:00:00+00:00 List-Id: In article , Matthew Heaney wrote: >In article , nospam@thanks.com.au wrote: > >>IMO, there's no excuse for imposing dependency-related ordering >>in an age of multi-pass compilation. > >Note that many computer scientists, among them Tony Hoare, believe that a >measurement of goodness of a language is its ability to be compiled using a >single pass. Holy cow. I'm hard pressed to think of a criterion less relevant to judging a computer language than this. Does Mr. Hoare provide an explanation for his position on this? >In that tradition, Ada was design so that it could be >compiled in a single pass. Note than given a high enough memory-cleverness product, any language can be processed in one pass. Worst case, the entire text of the program is read into memory (the one and only pass) and processed there. Of course, we can normally do better than that. I find it amazing that this issue is given so much weight. It's not even the most important issue in compiler efficiency. Look at C++: it's designed to be processed in one pass, but its use of header files which need to be re-parsed for each compilation unit is inherently inefficient. Precompiled headers help a lot, but the point is that its one-pass nature doesn't. >>Does the Ada95 standard impose dependency-related ordering? > >Ada was designed in the belief that the source text of a program has two >consumers: the human reader, and the Ada compiler. As such, the Ada >philosophy is that, when reading the code, one's understanding of the code >should only depend on what has come before. So yes, if there is a >dependency ordering between two subprogram bodies, then either the >dependent body must follow the other, or a specification for the body must >preceed the dependent body (subprogram specs can appear in the package >body). For the human understanding part, assuming that a person will only understand what came before also means assuming that the source text will be read in a linear fashion, which (in my experience) does not seem to be an actual limitation of humans. >That there is a dependency-related ordering in Ada (both 83 and 95) is by >design; that was the precise intent of Ada's designers. This should be >regarded as a Good Thing, because it makes it easier for the human reader >to apprehend program text. I understand why it might be regarded as a Good Thing, but I'm more inclined to regard it as an Unnecessary Restriction. >The same philosophy applies to exits from inside a loop > >loop > > > > exit when > > > >end loop; > >Many programmers think that it's better to use a while loop, ie > >while not Done loop > > > > Done := True; > > if not Done then > > end if; > >end loop; > >But this is much worse solution, not only because it requires introduction >of a flag, but because the human reader has to think about what happens >_after_ the flag gets set (does anything else need to get executed prior to >the end of the loop?). The poor reader has to study the _entire_ loop. I know that this point is incidental to the thread, but... I agree that this is not always better, but I wouldn't call it "much worse". What I would like to see is a loop structure like this: while not (Done or Error_Occurred) loop ... if(Some condition) exit because Error_Occurred; ... if(Some other condition) exit because Done; ... end loop; This seems to me to have several advantages: 1. The exit conditions are in the header of the loop, concentrated in one place for easy understanding of the loop. 2. It eliminates the nested if statements which would be required for #1 if the "exit" command didn't exist. 3. When the "exit" command is encountered, the reader does not have to be concerned with the rest of the loop. 4. After the loop, the reason for the termination can be determined: while not (Done or ErrorOccurred) loop ... end loop; if(Done) then ... end if; else if(ErrorOccurred) then ... end if; Of course, full understanding of a loop is impossible without studying the entire body, but I think this methodology makes it as understandable as possible without having to do that. (BTW, notice how the body of the loop can be ellided in the above example because all the necessary information is in the header.) >With the exit approach, comprehension only depends on what has come before. Yes, there seems to be an analogy here, but I think it's superficial. Certainly the statement "comprehension dependy only on what has come before" applies in both cases, but let's consider whether this is really important. In the loop-with-exit-flag case, the loop should logically terminate when a condition occurs, but the coding style does not force this, so the programmer is forced to inspect the code which follows the exit command even though logically it should do nothing. In the entity-declaration case, we're talking about attaining a higher level of abstraction by separating the declaration of an entity from its implementation. Does it really matter to the human if the implementation comes before or after the usage? Consider this: the reason for this abstraction is that the human reader need not be bothered with unnecessary details. If these details are unnecessary, who cares where they go? And if they *are* necessary, then a human reader searching a single text file with any reasonable editor should have no trouble finding it. Granted, this is not an argument against dependency-driven ordering, but merely a rebuttal of your argument in favour of it. -PD -- -- Patrick Doyle doylep@ecf.utoronto.ca