home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / rexx / 786 < prev    next >
Encoding:
Internet Message Format  |  1992-08-25  |  3.2 KB
  1. Path: sparky!uunet!usc!sol.ctr.columbia.edu!eff!snorkelwacker.mit.edu!bloom-beacon!eru.mt.luth.se!lunic!sunic!aun.uninett.no!ugle.unit.no!ugle!anders
  2. From: anders@lise3.lise.unit.no (Anders Christensen)
  3. Newsgroups: comp.lang.rexx
  4. Subject: Re: do over stem
  5. Message-ID: <ANDERS.92Aug26061644@lise3.lise.unit.no>
  6. Date: 26 Aug 92 04:16:44 GMT
  7. References: <179f67INNkfm@stanley.cis.Brown.EDU> <ANDERS.92Aug25001604@lise3.lise.unit.no>
  8.     <1992Aug26.025338.1@sejnet.sunet.se>
  9. Sender: news@ugle.unit.no (NetNews Administrator)
  10. Organization: /home/flipper/anders/.organization
  11. Lines: 58
  12. In-Reply-To: eric@sejnet.sunet.se's message of Wed, 26 Aug 1992 02:53:38 GMT
  13.  
  14. In article <1992Aug26.025338.1@sejnet.sunet.se> eric@sejnet.sunet.se (Eric Thomas) writes:
  15.  
  16. > [about the  'do i over stem.'  construct]
  17.  
  18. I don't think there is really any technical problems with implementing
  19. such a construct, either function-based or as part of 'do'.  Some
  20. problems have already been pointed out, but none so big that is
  21. impossible to do.
  22.  
  23. My main objection is not technical, but "Does it belong in Rexx?"
  24.  
  25. Eric Thomas posted some pieces of code, which could have been
  26. simplyfied a lot if a 'do i over stem' existed, and I agree that there
  27. is a need for such a construct. But the question is rather, "Does the
  28. need justify adding the feature to the definition of Rexx?". 
  29.  
  30. For every new feature in Rexx, the definition of the language
  31. increases, and the language becomes more complicated for new users to
  32. learn. For those who already know Rexx well (includes most of the
  33. readers of this group), the addition of a simple feature might not be
  34. a big deal. But for language itself, the accumulation of many simple
  35. features can make Rexx big, complex and difficult to learn for new
  36. users.
  37.  
  38. As for the construct itself, I like the 'do foo over bar.' best, since
  39. all the function-based solutions I have seem looks like some sort of
  40. kludge to me. 
  41.  
  42. What about letting 'var over stem." be an alternative 'repetitor' in
  43. do clauses. Then it would be possible to do something like:
  44.  
  45.    do <var> over <stem.>  { while <exprw> | until <expru> }
  46.  
  47. then <var> would be the control variable, which could be given as
  48. arguement to 'leave' and 'iterate', or be put after 'end'. Perhaps the
  49. 'for <exprf>' should be allowed in the repetitor too? I'm not so sure,
  50. it is just a random thought. Anyway, the only change in the old syntax
  51. would be to have 'OVER' be a reserved word in the repetitor.
  52.  
  53. It would work something like: <var> is 'iterated through' the tails
  54. which the stem <stem.> had at the moment when the do-loop was entered.
  55. At each iteration, <var> is set to the name of a new tail.  If <var>
  56. is a compound with stem <stem.> it is not included in the list of
  57. stems to be iterated over, unless it was already set before the
  58. do-loop. The 'until' part is checked at the end of each iteration,
  59. before <var> is incremented.  The 'while' is checked at the start of
  60. each iteration after <var> is assigned or incremented. The order in
  61. which the tails are assigned to <var> is arbitrary. Any setting or
  62. dropping of compounds with stem <stem.> during the loop, has no effect
  63. on the looping.
  64.  
  65. Is this more or less the functionality you wanted?
  66.  
  67. > Now it's too late, I am moving away from REXX as fast as I can.
  68.  
  69. I'm sorry to hear that. 
  70.  
  71. -anders
  72.