home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / rexx / 989 < prev    next >
Encoding:
Text File  |  1992-09-10  |  3.9 KB  |  89 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%92091111123047@DEARN>
  5. Newsgroups: comp.lang.rexx
  6. Date:         Fri, 11 Sep 1992 10:46:51 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 Thu,
  11.               10 Sep 92 15:52:07 GMT from <zjlc12@HOU.AMOCO.COM>
  12. Lines: 75
  13.  
  14. Hi REXXer,
  15.  
  16. on Thu, 10 Sep 92 15:52:07 GMT Jerry Campbell said:
  17.  
  18. > [...] from a programmer's point of view I don't want anyone messing
  19. > with my data!! If there are tabs in the data, I want to see them!! I
  20. > want as much control over the data as I can get.
  21.  
  22. When you want control over every character in your data, you will use
  23. character oriented operations, as
  24.   - positional parsing,
  25.   - literaL string, and variable (i.e. a variable in brackets), parsing,
  26.   - the last variable in a row of variables and single periods,
  27.   - character-position oriented, built-in, functions (such as SUBSTR),
  28.   - strict comparison operators.
  29.  
  30. When you want to give up control over every single character because you
  31. are only interested in numeric values, say, you will use decimal-numeric
  32. oriented operations, as
  33.   - numeric operators,
  34.   - numeric oriented functions (such as FORMAT),
  35.   - non-strict (aka "normal", or "weak") comparison operators.
  36. None of these will discriminate among e.g. the following data values:
  37.   "3.14159"
  38.   " 3.14159 "
  39.   ".0314159E2"
  40.   "3141.59E-3"
  41.   "+3.14159"
  42.   "003.14159"
  43.   "3.141590000"
  44. Though these operations ignore leading and trailing blanks, zeroes and
  45. plus-signs in particular places, and even interprete floating-point
  46. representations, nobody ever has complained that these are "messing
  47. with his or her data", have they?
  48.  
  49. On the very same account, when you want to give up control over every
  50. single character because you are only interested in words, you will use
  51. word oriented operations, as
  52.   - variables and single periods in a row (followed by a single
  53.     period) in parsing templates,
  54.   - word oriented functions (such as SPACE and SUBWORD),
  55.   - non-strict (aka "normal", or "weak") comparison operators (with
  56.     some care so they be not mistaken as numeric comparisons).
  57.  
  58. Every program exploiting word-oriented operations will intrinsically
  59. give up controll over the exact number of blanks. What is so horrible
  60. about the idea of extending these operations, reasonably, to cover *all*
  61. instances of words the programmer would expect in a given environment?
  62. Nobody has ever proposed to take control away from the programmer!
  63. Everybody shall be free to apply the operations best suited to his or her
  64. problem -- even in REXX :-)
  65.  
  66. > I'd want Parse to behave in a totally literal way, the same way I'd
  67. > expect the "strict" methods to behave. I can't believe anyone would
  68. > want to take  a basic language element like Parse and make it behave
  69. > differently than other character oriented language elements. Parse
  70. > should not have an opsys fudge factor built in.
  71.  
  72. This is in contrast to the agreed parts of the REXX definition. REXX
  73. has already word-oriented operations (including particular elements in
  74. parsing patterns, as outlined above and detailed in my previous poster)!
  75. PARSE is neither totally character oriented, nor totally word oriented:
  76. it depends on the pattern element you apply.
  77.  
  78. Of course, this poster is by no means meant to point at a particular
  79. person. Jerry's remarks came just handy as an illustration of the --
  80. still prevailing -- misunderstanding. I hope, the above comparison with
  81. numeric operations may render the distinction between various types of
  82. REXX operations somewhat clearer, and may help to confine the discussion
  83. to the relevant point, viz. how word-oriented operations should be
  84. defined (not touching character-oriented operations, at all).
  85.  
  86. Happy programming,
  87.      Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
  88.         <RZOTTO@nyx.uni-konstanz.de>
  89.