jsdy@SEISMO.ARPA (01/08/85)
The Software Tools Users' Group (STUG) long ago had available a version of Ratfor that contained hashed longnames. This reminds me that there are several things we can learn from the distributed authors of the best free compiler around. When I get in to the office, I'll have to check, but -- are break (n) and continue (n) in the ANSI Proposed Standard yet? (If you couldn't guess, the one breaks (n) levels of code structures -- case's, while's, etc. -- while the other continues with the n'th enclosing loop.) Yes, I recognise the existence of setjmp() and longjmp(), but get queasy at the thought of any kind of jump. Joe Yao (UUCP!seismo!hadron!jsdy / hadron!jsdy@seismo.ARPA)
Doug Gwyn (VLD/VMB) <gwyn@Brl-Vld.ARPA> (01/08/85)
Yuck! "break <n>;" is an accident looking for a place to happen! If one has to have this facility, "break <label>;" is far superior.
ron@brl-tgr.ARPA (Ron Natalie <ron>) (01/09/85)
> Yuck! "break <n>;" is an accident looking for a place to happen! > If one has to have this facility, "break <label>;" is far superior. And "goto <label>" is even better, you don't have to change the language at all. -Ron
sde@mitre-bedford.ARPA (01/09/85)
|> Yuck! "break <n>;" is an accident looking for a place to happen! |> If one has to have this facility, "break <label>;" is far superior. | |And "goto <label>" is even better, you don't have to change the language |at all. | |-Ron | Ron, perhaps you missed the point. The major objection to GOTO's is that they can lead to spaghetti code, but "break <label>" cannot do so, as it allows only a clearly limited type of downward escape, while avoiding the pitfalls of having to count nesting levels. David sde@mitre-bedford
Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> (01/09/85)
I'm sure Ron will have his own response too, but: One can reasonably contemplate upward-compatible extensions to C. One CANNOT seriously consider removal of heavily-used features such as "goto". Since "goto" will be in the language anyway, it can be used to accomplish what "break <label>" would. I would hope that all participants in this discussion realize why "goto" is thought ill of with respect to designing a NEW language.
nather@utastro.UUCP (Ed Nather) (01/09/85)
[] >Yuck! "break <n>;" is an accident looking for a place to happen! >If one has to have this facility, "break <label>;" is far superior. Or use "goto <label>" and leave C alone!
sde@mitre-bedford.ARPA (01/09/85)
Please don't attribute to me something I didn't say. I was not advocating the elimination of goto's from C, but felt the put-down of the idea of break <label> might not have been well thought out.
rpw3@redwood.UUCP (Rob Warnock) (01/10/85)
+--------------- | Yuck! "break <n>;" is an accident looking for a place to happen! | If one has to have this facility, "break <label>;" is far superior. +--------------- I second the motion. The BLISS-10 language (which has no explicit "goto") originally had "EXITWHILE" and "EXITCASE" and "EXITBLOCK" and... so they added a simple "EXIT n". Well, after a while they got tired of the hassle and replaced all that with labelled blocks so you can "LEAVE label". In pseudo-C: foo:{ ... ... break foo; ... } If one were to add this to "C" I would suggest somehow managing to force a label onto the END of the block which matches the one at the beginning, so that it is easy to scan forward and see where the block ends. But note that "C" already HAS this construct, if one doesn't mind some disciplined use of "goto". (I have seen this style already in some code.) Simply put the label just INSIDE the END of the block: #define leave goto /* preferably deep in a header file */ ... { /*BLOCK foo*/ ... ... leave foo; ... foo:} ... The point of using "leave" rather than "goto" is to emphasize that one is using a hierarchical control flow, and not jumping all over the place. Again, the disclipline of labeling the block entry is very important, as otherwise the reader hits the "leave foo" without knowing he/she is IN "foo"! (Any flamers about "goto" should recognize first that "return" is in fact just such a structured forward "goto". Dijkstra's paper was about the UNRESTRICTED use of "goto", not the existence of it at all.) Whether or not you have it in the compiler is not particularly important as far as code generation -- a decent data-flow/control-flow analyzer can easily deal with such forward-and-out "goto"s -- nor to ENFORCE the discipline (since as long as "C" has the unrestricted "goto" one must hope the programmer does not write spagetti code), but simply so that the compiler could check that the brackets and labels match (no use of "leave label" if we're not in a block named "label"). So finally, perhaps we should simply extend "lint" to warn of any "goto" whose target is not just inside the end of an enclosing block, and leave the poor compiler alone! (One could even get "lint" to check that the block started with a "/*BLOCK foo*/" comment!) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
thomas@utah-gr.UUCP (Spencer W. Thomas) (01/10/85)
This topic was extensively hacked over in this list only 2 or 3 months
ago. Are peoples memories _r_e_a_l_l_y that short????
Please desist.
--
=Spencer
({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)
<<< Silly quote of the week >>>mat@hou4b.UUCP (Mark Terribile) (01/10/85)
> -- are break (n) and continue (n) in the ANSI Proposed Standard yet? (If > you couldn't guess, the one breaks (n) levels of code structures -- case's, > while's, etc. -- while the other continues with the n'th enclosing loop.) > Yes, I recognise the existence of setjmp() and longjmp(), but get queasy at > the thought of any kind of jump. I hope these NEVER get in! This is a great way to write fragile code, and there is a MUCH more durable way to get what you are trying to get Why is it fragile? Well, it's easy to break it accidentally when you rework code. while( ... ) switch( ... ) { case ..: ... lots of code ... break 2; ... lots more code ... break; case ..: ... } What happens when that ``lots of ... lots more code'' gets surrounded by another loop or another switch in the course of the program's evolution? This is a great pitfall for ``the next guy'' who is going to use this code. This design is only pleasing to sociopaths. One better way is with (horrors) a label. Both ADA and (extended) PL/I do this, and it seems to work pretty well. The exact forms differ from language to language, but in C it might take the form of while( ... ) command_char: switch( ... ) { case ..: ... lots of code ... break command_char; ... lots more code ... break; case ..: ... } This is now solidly immune to the addition of new levels of control between the structure to be ``broken'' and the decision to break it. -- from Mole End Mark Terribile (scrape .. dig ) hou4b!mat ,.. .,, ,,, ..,***_*.
ron@brl-tgr.ARPA (Ron Natalie <ron>) (01/10/85)
> |And "goto <label>" is even better, you don't have to change the language > |at all. > | > |-Ron > > Ron, perhaps you missed the point. The major objection to GOTO's is that they > can lead to spaghetti code, but "break <label>" cannot do so, as it allows > only a clearly limited type of downward escape, while avoiding the pitfalls > of having to count nesting levels. > > David sde@mitre-bedford I do understand the point, but BREAK-TO is not structred anymore than any sort of gotos. If you just say, it's OK to user goto's rather only in these well-defined casees, you can get by WITHOUT MAKING GRATUITOUS AND UNNECESSARY CHANGES TO THE LANGUAGE. BREAK-TO is a total unnecessary change. You're not going to be able to get rid of goto (one of the nice things about C is that it allows careful programmers to break the structure and typing rules), adding break-to is redundant. -Ron
murphy%lll-tis.arpa@lll-tis (Thomas Murphy) (01/11/85)
> > > |And "goto <label>" is even better, you don't have to change the language > > |at all. > > | > > |-Ron > > > > Ron, perhaps you missed the point. The major objection to GOTO's is that they > > can lead to spaghetti code, but "break <label>" cannot do so, as it allows > > only a clearly limited type of downward escape, while avoiding the pitfalls > > of having to count nesting levels. > > > > David sde@mitre-bedford > > I do understand the point, but BREAK-TO is not structred anymore than > any sort of gotos. If you just say, it's OK to user goto's rather only > in these well-defined casees, you can get by WITHOUT MAKING GRATUITOUS > AND UNNECESSARY CHANGES TO THE LANGUAGE. BREAK-TO is a total unnecessary > change. You're not going to be able to get rid of goto (one of the nice > things about C is that it allows careful programmers to break the structure > and typing rules), adding break-to is redundant. > > -Ron By this reasoning we can quickly reduce ourselves to working with a turing machine. A while statement is redundant because we have goto and if statements. "break <label>" reflects a structured concept that mirrors how I view a problem being solved; besides it is not as random and clumsy as a goto. Tom murphy@lll-tis
bbanerje@sjuvax.UUCP (B. Banerjee) (01/13/85)
| > Yuck! "break <n>;" is an accident looking for a place to happen! | > If one has to have this facility, "break <label>;" is far superior. | | And "goto <label>" is even better, you don't have to change the language | at all. | | -Ron Yo folks! Howzabout # define break_to goto . . break_to <label> Voila! you have your semantic sugar, whilst the rest of us recalcitrant types can use 'goto' to break multi-level loops, WITHOUT changing the language. What is that you say? You like labelling your loops at the top? Sorry! Ever hear of backward goto's, and how confusing they are? The natural process of reading (code or otherwise) happens to be forward. -- Binayak Banerjee {allegra | astrovax | bpa | burdvax}!sjuvax!bbanerje P.S. Send Flames, I love mail.