home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #26 / NN_1992_26.iso / spool / comp / arch / 10441 < prev    next >
Encoding:
Internet Message Format  |  1992-11-07  |  3.6 KB
  1. Xref: sparky comp.arch:10441 comp.lang.misc:3515
  2. Path: sparky!uunet!charon.amdahl.com!pacbell.com!decwrl!sdd.hp.com!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!stanford.edu!rutgers!modus!gear!cadlab!martelli
  3. From: martelli@cadlab.sublink.org (Alex Martelli)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: A challenge to the anti-goto
  6. Message-ID: <1992Nov04.093942.13535@cadlab.sublink.org>
  7. Date: 4 Nov 92 09:39:42 GMT
  8. References: <1css0nINNc51@agate.berkeley.edu> <Bwznzx.Dr1@mentor.cc.purdue.edu> <Bx0BuG.s4@mentor.cc.purdue.edu> <1cvoctINNmhs@agate.berkeley.edu>
  9. Organization: CAD.LAB S.p.A., Bologna, Italia
  10. Lines: 82
  11.  
  12. jhauser@pine.CS.Berkeley.EDU (John Hauser) writes:
  13.     ...[I'm just excerpting bits from the code:]...
  14. :start:
  15. :    g = ...;
  16. :    switch ( g ) {
  17. :        case 1:
  18. :            n += 1;
  19. :            goto start;
  20. :        case 3:
  21.     ...
  22. :        case 12:
  23. :            goto start;
  24.     ...
  25. :            if ( g != 0 ) goto start;
  26.     ...
  27. :                if ( g & 3 != 2 ) goto start;
  28. :                j = 7;
  29. :                while ( ! ..bit.. ) {
  30. :                    j += 1;
  31. :                    g = ...;
  32. :                    if ( ( 2<<( g - 1 )/j ) & 1 == 0 ) goto start;
  33. :                }
  34.  
  35. :    When coded in C, Herman's algorithm cannot be efficiently
  36. :    implemented without at least one label (`start'), and
  37. :    corresponding `goto's.
  38. :(I look forward to seeing this claim refuted!)
  39.  
  40. It seems to me that exactly ONE of the 5 "goto start" constructs may
  41. give problems:  the last one, since it's embedded within another loop.
  42. All others could be replaced easily by changing the "start:"  label into
  43. a "for(;;) {", add a corresponding "break;}" at the end of the loop, and
  44. changing all "goto start;" into "continue;"; so at least 80% of the
  45. "corresponding `goto's" are removed (whether it is at all "beneficial"
  46. to do so is another question, of course!).
  47.  
  48. Break-from-loop and iterate-loop from within another nested loop (and,
  49. due to the 'overloaded' nature of the break keyword, break-from-loop
  50. from within a switch!) are indeed a functional limitation of C, i.e.,
  51. no can do without goto or some flag-variable.
  52.  
  53. :    If we've known about this problem for twenty years, why don't we
  54. :    have more powerful `break' instructions in our existing languages??
  55. :
  56. :Beats me.
  57.  
  58. But we DO.  The hugely popular perl language allows one to label a loop
  59. and use the label as an operand of the "next" (same as C "continue")
  60. and "last" (same as C "break") keywords.  I seem to recall that PL/I
  61. used a similar idea, and perhaps REXX, another very popular language.
  62. Just to clarify, the above could be something like:
  63.  
  64. mainloop: for(;;) {
  65.     ...
  66.     next mainloop if ...some condition...;
  67.     ...
  68.     if(...other condition...) {
  69.     next mainloop;
  70.     }
  71.     ...
  72.     innerloop: while( ...whatever... ) {
  73.     ...
  74.     next mainloop if ...yet further condition...;
  75.     }
  76.     ...
  77.     last mainloop;
  78. }
  79.  
  80. (perl has a further refinement, in that a loop may have a generalized
  81.  "continue-block", but I don't think it's needed for anything except
  82.  fully express the semantics of for(;;) in terms of while() - somebody
  83.  is sure to correct me if I'm wrong!-).
  84.  
  85. I don't really see that anything beyond labeled loops is warranted in
  86. the way of "more powerful `break' instructions".  By the way, isn't
  87. this discussion by now totally out of charter for comp.arch and more
  88. appropriate for comp.lang.{perl,misc}?  We're talking about little
  89. more than syntactic sugar, after all, surely not deep architectural
  90. questions!
  91. -- 
  92. Email: martelli@cadlab.sublink.org                   Phone: ++39 (51) 6130360
  93. CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: ++39 (51) 6130294 
  94.