franka@mmintl.UUCP (Frank Adams) (03/18/88)
The more I program, the more convinced I become that the 'while' loop is a mistake. It just doesn't match the semantics of too many real loops. I would prefer something like the following: do ... while <exp> else ... end while ... while <exp> ... end do The key points are: (1) Exit from any point in the loop. (2) Multiple exits. (3) Code can be associated with any exit point. I would use a special keyword (forever) instead of the normal end (end do) in the case that the loop had no while's associated with it. The compiler should check that loops end in forever if and only if they have no while's. C at least lets me write such a loop, although it's awkward. (And missing the ability to exit from within an inner loop, unless I want to use a goto.) With many other structured languages, such a loop can be written only with goto's. (I am aware of the practice of using switches for exits, and consider it no better than the goto -- the resulting code suffers from the same readability and maintainability problems.) -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
mason@tmsoft.UUCP (Dave Mason) (03/28/88)
In article <2773@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: > >The more I program, the more convinced I become that the 'while' loop is a >mistake. It just doesn't match the semantics of too many real loops. >... >The key points are: > >(1) Exit from any point in the loop. >(2) Multiple exits. >(3) Code can be associated with any exit point. > In a language I designed for my students to implement in my compiler course loops look like: do ... while expr ... od where the while can go anywhere & there can be any number of them (or until's which are similar but with opposite logic). This leads to Pascal style while & repeat loops: do while expr ... od do ... until expr od as well as the more flexible forms. The do keyword can be followed by 1 or more 'for' clauses, which are stepped in parallel: int a[0..29] ... do for i in 1..20 for ap in a ... while i!=ap ... od equivalent to the C: int a[30]; ... {int i,*ap; for (i=1,ap=a;i<=20 && ap<&a[sizeof(a)/sizeof(int)];++i,++ap) { ... if (i!=*ap) break; ... }} Notes: 1) loop control variables have a scope of the loop 2) loop control variables traversing an array (or list or other linked structure) are aliases for the current element 3) all the efficiency of C pointer arithmetic 4) all the safety of Pascal subscript calculation (and more if we were to make the aliased array be not directly usable in the loop scope, but I want them to be able to implement a reasonable subset in a semester :-) 5) controlled break out of outer loops (continue, break) (do, while, until, continue, break all have optional labels) From the sample programs I've written in this language, this seems like a very reasonable and natural loop structure. (BTW, Frank's idea already exists in at least Concurrent Euclid, Turing: loop ... exit when a<>b ... end loop ) ../Dave
dhesi@bsu-cs.UUCP (Rahul Dhesi) (03/30/88)
In article <294@tmsoft.UUCP> mason@tmsoft.UUCP (Dave Mason) writes: >In a language I designed for my students to implement in my compiler >course loops look like: > do > ... > while expr > ... > od >where the while can go anywhere & there can be any number of them... Unfortunately, somebody modifying code with such a construct will seldom be sure that he has tracked down all the exit points. The same problem exists with goto, exit, break, etc. A possible solution: do (2 exits) ... while expr ... while expr ... done The assertion "(2 exits)" tells the compiler to flag a syntax error if the number of loop exits is not exactly 2. The default, in the absence of this assertion, could be exactly one exit. Also "(no exits)". -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
pabuhr@watmsg.waterloo.edu (Peter A. Buhr) (03/30/88)
In article <2488@bsu-cs.UUCP> dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: >In article <294@tmsoft.UUCP> mason@tmsoft.UUCP (Dave Mason) writes: >>... >Unfortunately, somebody modifying code with such a construct will >seldom be sure that he has tracked down all the exit points. The same >problem exists with goto, exit, break, etc. > >A possible solution: > > do (2 exits) > ... > while expr > ... > while expr > ... > done > >The assertion "(2 exits)" tells the compiler to flag a syntax error if >the number of loop exits is not exactly 2. The default, in the absence >of this assertion, could be exactly one exit. Also "(no exits)". A much easier solution is to outdent the exit conditions, as in: do ... while expr ... while expr ... done It is then possible to scan down the margin of the loop and see very quickly all the exit points. This is the same mechanism that is used to locate the else clasue of an if statement, as in: if ... then if ... then ... ... else vs. else .... ... end if end if For a more detailed discussion on this stuff see: Buhr, P. A. A Case for Teaching Multi-exit Loops to Beginning Programmers. SIGPLAN Notices, vol. 20, no. 11, November 1985, pp. 14-22
franka@mmintl.UUCP (Frank Adams) (03/31/88)
In article <294@tmsoft.UUCP> mason@tmsoft.UUCP (Dave Mason) writes: >In article <2773@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >>The more I program, the more convinced I become that the 'while' loop is a >>mistake. It just doesn't match the semantics of too many real loops. >>... >>The key points are: >>(1) Exit from any point in the loop. >>(2) Multiple exits. >>(3) Code can be associated with any exit point. I want to re-emphasize point (3) here. In a structured program, there should be a (relatively) simple statement of the state of the computation when you exit from the loop. When there are multiple bare exit points, it is likely that the simplicity of that condition must be sacrificed. This leads to things like (in pseudo-code): for i = 1 to n; ... while P(i); ... end; if i > n /* Check for normal exit from loop */ ... or even worse kludges. (I want to emphasize that this is a practical objection as well as a theoretical one.) The examples Dave gives are all missing this facility. >... The do keyword can be followed by 1 or more 'for' clauses, which are >stepped in parallel: > int a[0..29] > ... > do > for i in 1..20 > for ap in a > ... > while i!=ap > ... > od Add optional exit code for each for and while, and you've got my approval. E.g., for i in 1..20 else f(t) rof >(BTW, Frank's idea already exists in at least Concurrent Euclid, Turing: > loop > ... > exit when a<>b > ... > end loop -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
dhesi@bsu-cs.UUCP (Rahul Dhesi) (04/01/88)
In article <17911@watmath.waterloo.edu> pabuhr@watmsg.waterloo.edu (Peter A. Buhr) writes: >A much easier solution is to outdent the exit conditions... ... >It is then possible to scan down the margin of the loop and see very >quickly all the exit points. This leaves all the responsibility in the hands of the programmer, much as weak typing and implicit variable declarations do. -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
erlebach@turing.toronto.edu (Beverly Erlebacher) (04/02/88)
<294@tmsoft.UUCP> <2797@mmintl.UUCP> Reply-To: erlebach@turing.UUCP (Beverly Erlebacher) Organization: University of Toronto, CSRI >In article <294@tmsoft.UUCP> mason@tmsoft.UUCP (Dave Mason) writes >>>The more I program, the more convinced I become that the 'while' loop is a >>>mistake. It just doesn't match the semantics of too many real loops. >>>(1) Exit from any point in the loop. >>>(2) Multiple exits. >>>(3) Code can be associated with any exit point. > >I want to re-emphasize point (3) here. In a structured program, there >should be a (relatively) simple statement of the state of the computation >when you exit from the loop. When there are multiple bare exit points, it >is likely that the simplicity of that condition must be sacrificed. This > > for i = 1 to n; > ... > while P(i); > ... > end; > > if i > n /* Check for normal exit from loop */ > ... >or even worse kludges. (I want to emphasize that this is a practical >objection as well as a theoretical one.) >The examples Dave gives are all missing this facility. >Add optional exit code for each for and while, and you've got my approval. Dave's example doesn't include one of the features Frank is looking for. In addition to loop ... exit when condition ... end loop Turing has an even more general loop exit: loop ... if condition then ... exit ... end loop This allows statements to be conveniently associated with any of several exits. The Turing for loop also allows both styles of exit statement. I hope this wins Frank's approval. :-) ----------------------------- B.A.Erlebacher erlebach@csri.toronto.edu
jk3k+@andrew.cmu.edu (Joe Keane) (04/02/88)
(Childish flame alert?) You want to see contorted code? Look at someone
trying to wrestle out of Pascal's loop constructs with boolean flags. At least
with lots of goto's you've only to worry about one state: where you are in the
program. With this code, you have to cross this with the possible combinations
of flags. I want to call the style police when i see this (and don't even
think about nested loops):
done := false;
while not done do begin
do_some;
if done_now then
done := true
else
do_some_more;
if done_already then
done := true;
{ leaving out the else causes a mess }
do_even_more
end
--Joejohn@bby-bc.UUCP (john) (04/04/88)
In article <AWJ9X4y00WAHE53kVi@andrew.cmu.edu>, jk3k+@andrew.cmu.edu (Joe Keane) writes: > of flags. I want to call the style police when i see this (and don't even > think about nested loops): > > done := false; > while not done do begin > do_some; > if done_now then > done := true > else > do_some_more; > if done_already then > done := true; > { leaving out the else causes a mess } > do_even_more > end Well it doesn't have to look that bad. done := false; while not done do begin do_some; done := done | done_now; if not done then begin do_some_more; done := done | done_already; end; else do_even_more; end; I don't quite understand your { ... causes a mess} comment; I had to guess - is do_even_more supposed to execute if done_already is false?
nevin1@ihlpf.ATT.COM (00704a-Liber) (04/05/88)
In article <270@bby-bc.UUCP> john@bby-bc.UUCP (john) writes: > Well it doesn't have to look that bad. > done := false; > while not done do begin > do_some; > done := done | done_now; > if not done then begin > do_some_more; > done := done | done_already; > end; > else do_even_more; > end; I'm sorry, but to all but Pascal/Modula-2 programmers, this does look bad!! Why should I have to have 9 or 10 levels of nesting so that I can 'fall off the end of the loop'. All this does is obscure the fact that I want to do to the end of the loop. This is one of the pluses of the 'break' statement in C (although it is not general enough, but I don't want to start that discussion again :-)). >I don't quite understand your { ... causes a mess} comment; I had to guess >- is do_even_more supposed to execute if done_already is false? I think what he meant by leaving the 'else' clause off (a mistake about as common as putting an = instead of a == in C), is that once you determine that this loop is finished, no more code within it should be executed. If the else clause isn't there then unwanted execution probably occurs (ie, do_even_more is suppose to be executed *only* if done_already is false). If the style was good, you shouldn't of had to guess when do_even_more is suppose to be (and not suppose to be) executed. -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
jk3k+@andrew.cmu.edu (Joe Keane) (04/05/88)
While i'm at childish flaming, i might as well say that i _really_ hate `fi', `rof', `esac', and `elihw'. Can anyone say they're a good idea and keep a straight face? --Joe
dhesi@bsu-cs.UUCP (Rahul Dhesi) (04/05/88)
In article <2797@mmintl.UUCP> franka@mmintl.UUCP (Frank Adams) writes: >In a structured program, there >should be a (relatively) simple statement of the state of the computation >when you exit from the loop. The Zahn control structure, described in the literature, accomplishes this. But the Ada designers explicitly discussed this and decided not to include it because the same can be done with the use of a variable to hold the exit status, the general exit statement in a loop then becoming: if condition1 then exit_status:=NORMAL_EXIT; exit; end if; -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
gast@lanai.cs.ucla.edu (David Gast) (04/08/88)
In article <294@tmsoft.UUCP> mason@tmsoft.UUCP (Dave Mason) writes: >In a language I designed for my students to implement in my compiler >course loops look like: > do > ... > while expr > ... > od >where the while can go anywhere & there can be any number of them (or >until's which are similar but with opposite logic). This leads to >Pascal style while & repeat loops: >The do keyword can be followed by 1 or more 'for' clauses, The semantics are similar to those provided by Algol 68. >Notes: >4) all the safety of Pascal subscript calculation While it is commonly believed that it is impossible to change the index variable in a for loop, it is possible to do so. Consider the following program. program illegal (output); {This program is not legal pascal, but the compiler does not detect the error. If the scope of the index variable were local to the for loop (ala Algol 68), instead of global, then this error would be detected at compiler time. } var i : integer; procedure illegal_assignment (k: integer); begin i := k + 10; {i is the index variable in the for loop} writeln (i) end; begin for i := 1 to 10 do begin illegal_assignment (i); writeln (i) end end. Although I have not read the latest Pascal standard, the Pascal I used has many insecurities. David Gast gast@cs.ucla.edu {ucbvax,rutgers}!ucla-cs!gast
Ralf.Brown@B.GP.CS.CMU.EDU (04/08/88)
In article <11047@shemp.CS.UCLA.EDU>, gast@lanai.cs.ucla.edu (David Gast) writes: }While it is commonly believed that it is impossible to change the }index variable in a for loop, it is possible to do so. Consider the }following program. } [code deleted for brevity] } }David Gast }gast@cs.ucla.edu }{ucbvax,rutgers}!ucla-cs!gast I don't know about Turbo Pascal 4.0, but versions 1 through 3 use a "hidden" variable for the loop counter, so you can change the visible loop counter to your heart's content and the loop will still execute exactly the same number of times. -- {harvard,ucbvax}!b.gp.cs.cmu.edu!ralf -=-=- DISCLAIMER? I claimed something? ARPA: RALF@CS.CMU.EDU FIDO: Ralf Brown 1:129/31 BIT: RALF%CS.CMU.EDU@CMUCCVMA TalkNet: (school) | "Tolerance means excusing the mistakes others make. (412)268-3053 | Tact means not noticing them." --Arthur Schnitzler
richard@aiva.ed.ac.uk (Richard Tobin) (04/11/88)
In article <YWK3hUy00VA88IO0UA@andrew.cmu.edu> jk3k+@andrew.cmu.edu (Joe Keane) writes: >While i'm at childish flaming, i might as well say that i _really_ hate `fi', >`rof', `esac', and `elihw'. Can anyone say they're a good idea and keep a >straight face? Yeah, I think they're great, especially 'tnemmoc' and 'nigeb'. And seriously, they can result in slightly better error detection than a system that uses the same (unlabelled) delimiters for different constructs. -- Richard -- Richard Tobin, JANET: R.Tobin@uk.ac.ed AI Applications Institute, ARPA: R.Tobin%uk.ac.ed@nss.cs.ucl.ac.uk Edinburgh University. UUCP: ...!ukc!ed.ac.uk!R.Tobin
ken@aiva.ed.ac.uk (Ken Johnson) (04/11/88)
How to allow breaking out of arbitrary loops, which you might otherwise have to do like this: >> done := false; >> while not done do begin >> do_some; >> done := done | done_now; >> if not done then begin >> do_some_more; >> done := done | done_already; >> end; >> else do_even_more; >> end; In some recent versions of Logo, and also in Lisp, you have the `throw/catch' construct, which I think looks a lot better: to a_program catch 'foo [ forever [ repeated_bit if <condition> [ throw 'foo ] other_repeated_bit ] ] last_bit When the `throw 'foo' is executed, execution resumes at `last_bit'. Catches may be nested. -- ------------------------------------------------------------------------------ From Ken Johnson, AI Applications Institute, The University, EDINBURGH Phone 031-225 4464 ext 212 Email k.johnson@ed.ac.uk
anw@nott-cs.UUCP (04/12/88)
In article <YWK3hUy00VA88IO0UA@andrew.cmu.edu> jk3k+@andrew.cmu.edu (Joe Keane) writes: >While i'm at childish flaming, i might as well say that i _really_ hate `fi', >`rof', `esac', and `elihw'. Can anyone say they're a good idea and keep a >straight face? Yes. "They're a good idea." :-| What's your problem -- the concept of closing off the loop properly, or the actual words? OK, the actual words aren't marvellous, but no-one has suggested anything better that I know of (I don't rate `end_if' and its relatives very highly), and they have an obvious provenance that goes well with the usual mathematical convention for paired brackets. The *concept* is undeniably a Good Idea, for three reasons: a) saves lots of `begin ... end' pairs, reducing code clutter & indentation; b) gives both compiler and human a clearer idea of where each construct ends; c) makes loops and conditionals a smaller piece of syntax with no ambiguity. (Examples supplied on request.) -- Andy Walker, Maths Dept., Nott'm Univ. anw@maths.nott.ac.uk
bobdi@omepd (Bob Dietrich) (04/12/88)
In article <11047@shemp.CS.UCLA.EDU> gast@lanai.UUCP (David Gast) writes: >While it is commonly believed that it is impossible to change the >index variable in a for loop, it is possible to do so. Consider the >following program. Sorry, but the existing ANSI/IEEE and ISO Pascal standards do not allow such modification. There is a concept called "threatening" explained under the for-statement (section 6.8.3.9). Basically, if a variable has been "threatened", it cannot be used as a for control variable. A variable is threatened when it appears as the target of an assignment, as a variable parameter, as the non-file parameter of read or readln, or if a statement enclosing the for-statement has the same control variable (a for-statement nested within a for-statement). These restrictions apply to routines nested within the current routine as well. This check can be done at translation (compile) time, and requires only a Boolean flag for variables that can be a for control. > >program illegal (output); > >{This program is not legal pascal, but the compiler does not detect the > error. If the scope of the index variable were local to the for loop > (ala Algol 68), instead of global, then this error would be detected > at compiler time. } > > var > i : integer; > > procedure illegal_assignment (k: integer); > begin > i := k + 10; {i is the index variable in the for loop} ^-- a threat to i (all it takes is one!) > writeln (i) > end; > > begin > for i := 1 to 10 do ^-- At this point threats to i are checked, and the violation detected. > begin > illegal_assignment (i); > writeln (i) > end > end. > >Although I have not read the latest Pascal standard, the Pascal I used >has many insecurities. This may well be, and is unfortunate. However, please try to separate the language from your particular implementation. Like any other language or tool, there's mediocre implemententations and excellent implementations, and a lot in-between. Speaking as both a compiler writer and a user, I suggest you beat on your vendor to get rid of the insecurities that are giving you problems, or take your business elsewhere if they don't respond. > >David Gast >gast@cs.ucla.edu >{ucbvax,rutgers}!ucla-cs!gast Bob Dietrich Intel Corporation, Hillsboro, Oregon (503) 696-4400 or 2092(messages x4188,2111) usenet: tektronix!ogcvax!omepd!bobdi or tektronix!psu-cs!omepd!bobdi or ihnp4!verdix!omepd!bobdi
rober@weitek.UUCP (Don Rober) (04/13/88)
In article <11047@shemp.CS.UCLA.EDU> gast@lanai.UUCP (David Gast) writes: > >While it is commonly believed that it is impossible to change the >index variable in a for loop, it is possible to do so. Consider the >following program. > [illegal program with threatening for loop reference deleted] While it is a pain, it it not really that difficult to enforce this area of the Pascal standard. When an assignment to a variable is made, the symbol table is marked noting a potentially threatening reference. When the for-loop is seen, the variable is checked to see if a threatening reference happened; if so, an error. (Appropriate care must be taken for threatening references that *follow* the for-loop.) The Unisys A-series compiler does this checking. It was interesting to see the number of otherwise "portable" programs that would fail with a standard-enforcing compiler.-- ---------------------------------------------------------------------------- Don Rober UUCP: {pyramid, cae780}!weitek!rober Weitek Corporation 1060 East Arques Sunnyvale, CA 94086
sommar@enea.se (Erland Sommarskog) (04/14/88)
Dr A. N. Walker (anw@nott-cs.UUCP) writes: >Joe Keane (jk3k+@andrew.cmu.edu) writes: >>While i'm at childish flaming, i might as well say that i _really_ hate `fi', >>`rof', `esac', and `elihw'. Can anyone say they're a good idea and keep a >>straight face? > > Yes. "They're a good idea." :-| > > What's your problem -- the concept of closing off the loop properly, >or the actual words? OK, the actual words aren't marvellous, but no-one has >suggested anything better that I know of (I don't rate `end_if' and its >relatives very highly), and they have an obvious provenance that goes well >with the usual mathematical convention for paired brackets. The bad point with words like "esac" is that you have to read them twice, at least, to see what's going on. The sole advantage over "end case" is that you save some keys to type. Whereas this seem to have been an important issue in some languages and operating systems, I wouldn't count that at all. "End case" is clearer. It also have the advantage that you only have to read "end" if you're just taking a quick glance; The fact that it is the end of a case-statement may be irrelevant at the moment. Ada has "end if", "end loop", "end case" and "end <name>". Unfortunately you can leave out names in end-statements for procedure and packages. And for blocks you can only have "end <name>" if you name the block, which you rarely do. (At least not me.) "end block" would be something. Note also that "end if" (or "fi" or whatever") helps you little when you have many nested if-statements. You're just as bad out as with only "end", unless you add a comments like: end if; -- test A end if; -- test B -- Erland Sommarskog ENEA Data, Stockholm - Hey, aren't you playing this record at 45 rpm? sommar@enea.UUCP - No, you're listening to Rush.
tim@amdcad.AMD.COM (Tim Olson) (04/16/88)
In article <340@aiva.ed.ac.uk> richard@uk.ac.ed.aiva (Richard Tobin) writes: |In article <YWK3hUy00VA88IO0UA@andrew.cmu.edu> jk3k+@andrew.cmu.edu (Joe Keane) writes: |>While i'm at childish flaming, i might as well say that i _really_ hate `fi', |>`rof', `esac', and `elihw'. Can anyone say they're a good idea and keep a |>straight face? | |Yeah, I think they're great, especially 'tnemmoc' and 'nigeb'. Reminds me of a paper I was just re-reading: "Design of a LISP-Based Microprocessor" by Steele et al. It contains a pseudocode listing of a state machine, which uses two constructs, "if" and "type-dispatch". The last state is: RETURN: TYPE-DISPATCH ON CLINK INTO "IF2": GOTO IF2 "EVCOM3": GOTO EVCOM3 HCTAPSID-EPYT !SESOL ARTSKJID -- Tim Olson Advanced Micro Devices (tim@amdcad.amd.com)
amos@taux01.UUCP (Amos Shapir) (04/17/88)
It's funny this subject has been going on for quite a while now, without anyone mentioning the article 'do..ob considered odder than do..od'. It's going to be even funnier if someone does - I think it was in Communications of the ACM last year, but I don't have the exact reference. -- Amos Shapir (My other cpu is a NS32532) National Semiconductor (Israel) 6 Maskit st. P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522261 amos%taux01@nsc.com 34 48 E / 32 10 N
ok@quintus.UUCP (Richard A. O'Keefe) (04/17/88)
In article <3041@enea.se>, sommar@enea.se (Erland Sommarskog) writes: : Dr A. N. Walker (anw@nott-cs.UUCP) writes: : >Joe Keane (jk3k+@andrew.cmu.edu) writes: : >>While i'm at childish flaming, i might as well say that i _really_ hate `fi', : >>`rof', `esac', and `elihw'. Can anyone say they're a good idea and keep a : >>straight face? : > Yes. "They're a good idea." :-| [I can say that too. "]" goes with "[", so why _not_ "fi" with "fi"?] : Ada has "end if", "end loop", "end case" and "end <name>". Note also : that "end if" (or "fi" or whatever") helps you little when : you have many nested if-statements. You're just as bad out as with : only "end", unless you add a comments like: : end if; -- test A : end if; -- test B SETL used to end everything with 'end', but you could supply some number of tokens after it, and the compiler would check that they exactly matched the beginning. E.g. if i < j ..... end [if [i [< [j ...]]]] I forget what the limit was, something like 3 tokens.
John_M@spectrix.UUCP (John Macdonald) (04/19/88)
In article <885@cresswell.quintus.UUCP> ok@quintus.UUCP (Richard A. O'Keefe) writes: :In article <3041@enea.se>, sommar@enea.se (Erland Sommarskog) writes: :: Dr A. N. Walker (anw@nott-cs.UUCP) writes: :: >Joe Keane (jk3k+@andrew.cmu.edu) writes: :: >>While i'm at childish flaming, i might as well say that i _really_ hate :: >>`fi', `rof', `esac', and `elihw'. Can anyone say they're a good idea and :: >>keep a straight face? :: > Yes. "They're a good idea." :-| :[I can say that too. "]" goes with "[", so why _not_ "fi" with "fi"?] :: Ada has "end if", "end loop", "end case" and "end <name>". Note also :: that "end if" (or "fi" or whatever") helps you little when :: you have many nested if-statements. You're just as bad out as with :: only "end", unless you add a comments like: :: end if; -- test A :: end if; -- test B : :SETL used to end everything with 'end', but you could supply some number of :tokens after it, and the compiler would check that they exactly matched the :beginning. E.g. : if i < j ..... end [if [i [< [j ...]]]] :I forget what the limit was, something like 3 tokens. My personal preference is for a technique used in SWL. It was more or less an extension of Pascal. All blocks were terminated with a unique terminator easily derived from the initiating token - add 'end' to the token, eliding double 'e's. Thus, while ... whilend, if ... ifend, repeat ... repeatend, proc ... procend, etc. (Just to prove that rules are meant to be broken, there was still the familiar begin ... end. Oh well.) I find this approach to be the easiest to quickly find the other bound of a unit, but I'm sure that other people have different preferences. SWL (Software Writers Language, pronounced swill, lots of Wizard of Id spook cartoons on the walls, bug reports featured the "there's a fly in my swill" cartoon) was developed jointly by CDC and NCR for their internal systems development use, including a joint computer line. It is still around. Within CDC, it has been renamed CYBIL (CYBer Implementation Language). Within NCR, I believe it also changed its name. -- John Macdonald UUCP: {mnetor,utzoo} !spectrix!jmm
nevin1@ihlpf.ATT.COM (00704a-Liber) (04/19/88)
In article <3041@enea.se> sommar@enea.UUCP(Erland Sommarskog) writes: |The bad point with words like "esac" is that you have to read them twice, |at least, to see what's going on. After the first couple of times, I had this one memorized. |The sole advantage over "end case" is that you save some keys to type. |[...] |"End case" is clearer. It also have the advantage that you only have to |read "end" if you're just taking a quick glance; The fact that it is the |end of a case-statement may be irrelevant at the moment. 'End case' usually takes me longer to read, since I usually read it as two separate English words vs. 'esac', which I consider to be a simply memorized end of case. |Note also that "end if" (or "fi" or whatever") helps you little when |you have many nested if-statements. You're just as bad out as with |only "end", unless you add a comments like: | end if; -- test A | end if; -- test B Oh, no!! You and I agree on something, again!! :-) -- _ __ NEVIN J. LIBER ..!ihnp4!ihlpf!nevin1 (312) 510-6194 ' ) ) "The secret compartment of my ring I fill / / _ , __o ____ with an Underdog super-energy pill." / (_</_\/ <__/ / <_ These are solely MY opinions, not AT&T's, blah blah blah
napoli@crin.crin.fr (Amedeo NAPOLI) (03/15/89)
Here is a sentence in the beginning of the LOOPS Manual (1983) : LOOPS grew out of our research in a knowledge representation language (called Lore) for use in a project to create an "expert assistant" for designers of integrated digital systems. Could somebody tell me if "integrated digital systems" means "integrated circuits" ? I am not sure, but the LOOPS Manual was referenced as a VLSI Group Memo. Many thanks for your help. "Au revoir" Napoli Amedeo -- --- Amedeo Napoli @ CRIN / Centre de Recherche en Informatique de Nancy EMAIL : napoli@crin.crin.fr - POST : BP 239, 54506 VANDOEUVRE CEDEX, France