home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10448 < prev    next >
Encoding:
Internet Message Format  |  1992-11-07  |  3.9 KB

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