home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.arch:10448 comp.lang.misc:3520
- Newsgroups: comp.arch,comp.lang.misc
- Path: sparky!uunet!europa.asd.contel.com!emory!sol.ctr.columbia.edu!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!hrubin
- From: hrubin@mentor.cc.purdue.edu (Herman Rubin)
- Subject: Re: A challenge to the anti-goto
- Message-ID: <BxAIAD.CIB@mentor.cc.purdue.edu>
- Organization: Purdue University Statistics Department
- References: <Bx0BuG.s4@mentor.cc.purdue.edu> <1cvoctINNmhs@agate.berkeley.edu> <1992Nov04.093942.13535@cadlab.sublink.org>
- Date: Fri, 6 Nov 1992 10:25:24 GMT
- Lines: 70
-
- In article <1992Nov04.093942.13535@cadlab.sublink.org> martelli@cadlab.sublink.org (Alex Martelli) writes:
- >jhauser@pine.CS.Berkeley.EDU (John Hauser) writes:
-
- ...............................
-
- >: When coded in C, Herman's algorithm cannot be efficiently
- >: implemented without at least one label (`start'), and
- >: corresponding `goto's.
- >:(I look forward to seeing this claim refuted!)
-
- >It seems to me that exactly ONE of the 5 "goto start" constructs may
- >give problems: the last one, since it's embedded within another loop.
- >All others could be replaced easily by changing the "start:" label into
- >a "for(;;) {", add a corresponding "break;}" at the end of the loop, and
- >changing all "goto start;" into "continue;"; so at least 80% of the
- >"corresponding `goto's" are removed (whether it is at all "beneficial"
- >to do so is another question, of course!).
-
- There are two questions here. One of them is producing workable code;
- and at least some of the responders have succeeded in showing that in
- some languages this can be done. I never doubted this. Also, remember
- that this was not my first posting of the code; I posted the version in
- which all control statements were by gotos, which BTW for someone who
- uses gotos is quite easy, more to make sure I had no C errors than as
- optimal code. Switch statements, normal writing of loops, etc., are
- quite fine with me.
-
- But the other part of my challenge is producing efficient code. To
- do this, it is necessary for the case 1 code to fall into start, and
- for the rejection cases, to have the case statement cause a transfer
- to start. Whether an implementation will cause
-
- case 3: break;
-
- to be a transfer to start, rather than a transfer to the case 3: code
- and then a transfer to start is problematical.
-
- In addition, I have seen no code (other than possibly the Lisp code
- which it will take me some work to read) which successfully avoids
- the gotos on exit from the loop to the label^n section of the code
- without using a construct which is essentially equivalent to it or
- by paying a price.
-
- >Break-from-loop and iterate-loop from within another nested loop (and,
- >due to the 'overloaded' nature of the break keyword, break-from-loop
- >from within a switch!) are indeed a functional limitation of C, i.e.,
- >no can do without goto or some flag-variable.
-
- >: If we've known about this problem for twenty years, why don't we
- >: have more powerful `break' instructions in our existing languages??
-
- >:Beats me.
-
- >But we DO. The hugely popular perl language allows one to label a loop
- >and use the label as an operand of the "next" (same as C "continue")
- >and "last" (same as C "break") keywords. I seem to recall that PL/I
- >used a similar idea, and perhaps REXX, another very popular language.
- >Just to clarify, the above could be something like:
-
- Is Perl suitable for code as I have written, or REXX. PL/I suffered
- from clumsy syntax, as does ADA and assembler, and from what I have
- seen of it, Lisp. For the person writing code, syntax is extremely
- important, and clumsy syntax does not help the reader. It MAY help
- the compiler, however; assemblers would have to work harder if the
- instruction mnemonic did not come first.
- --
- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
- Phone: (317)494-6054
- hrubin@snap.stat.purdue.edu (Internet, bitnet)
- {purdue,pur-ee}!snap.stat!hrubin(UUCP)
-