home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / rexx / 973 < prev    next >
Encoding:
Text File  |  1992-09-09  |  2.4 KB  |  50 lines
  1. Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
  2. Path: sparky!uunet!paladin.american.edu!auvm!DKNKURZ1.BITNET!RZOTTO
  3. X-Acknowledge-To: <RZOTTO@DKNKURZ1>
  4. Message-ID: <REXXLIST%92090916473059@DEARN>
  5. Newsgroups: comp.lang.rexx
  6. Date:         Wed, 9 Sep 1992 16:24:18 MEZ
  7. Sender:       REXX Programming discussion list <REXXLIST@UGA.BITNET>
  8. From:         Otto Stolz <RZOTTO@DKNKURZ1.BITNET>
  9. Subject:      Re: Blanks, REXX, and portability...
  10. In-Reply-To:  Message of Tue, 8 Sep 92 18:15:52 GMT from <zjlc12@HOU.AMOCO.COM>
  11. Lines: 37
  12.  
  13. On Tue, 8 Sep 92 18:15:52 GMT Jerry Campbell said:
  14. > [...] since there is so much controversy regarding this issue I'd
  15. > think that would be a clear sign that it should be left alone. The
  16. > programmer should worry about this white space vs. "real" blanks thing.
  17.  
  18. I think much of the controversy is arising from contributors not being
  19. aware what was actually proposed (including Jerry, I am sorry to say).
  20. In any case, a programming language standard simply *cannot* choose to
  21. leave a controversal issue alone -- on the contrary: the sole purpose
  22. of a standard is to settle controversies of this sort (viz. how a
  23. particular feature has to be understood and implemented). As TRL is based
  24. on a faulty assumption (only in this regard), the standard simply
  25. *cannot* incorporate its wording unaltered, or without any consideration.
  26.  
  27. > What if, I really, really did want to discriminately parse blanks as
  28. > opposed to tabs? Take a Rexx program that wanted to convert tabs to
  29. > real blanks or vice versa? [...]
  30.  
  31. In this case you would not want to parse your data into words, will you?
  32. Hence, the whole discussion simply does not apply to this case. You
  33. would use positional parsing, or the SUBSTR function, or whatever
  34. character-oriented (as opposed to word-oriented) operation you deem
  35. appropriate to get at the pieces of your data; and you would be well
  36. adviced to use strict comparison operators (even in the CMS implement-
  37. ation, to be sure your program can distinguish zero blanks from one
  38. blank).
  39.  
  40. > Please, don't build "intelligent" second guessing Rexx inter-
  41. > preters.....!   Or standards.
  42.  
  43. Agreed! But this guideline does not preclude intelligent (without
  44. quotes!), consistent, standrad-conforming, and usable interpreters.
  45. Or standards. That's what I think I have proposed, btw.
  46.  
  47. Happy programming,
  48.                     Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
  49.                                <RZOTTO@nyx.uni-konstanz.de>
  50.