home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / rexx / 940 < prev    next >
Encoding:
Internet Message Format  |  1992-09-08  |  3.0 KB
  1. Path: sparky!uunet!gatech!concert!borg!news_server!martinc
  2. From: martinc@grover.cs.unc.edu (Charles R. Martin)
  3. Newsgroups: comp.lang.rexx
  4. Subject: Re: Blanks, REXX, and portability...
  5. Message-ID: <MARTINC.92Sep8132026@grover.cs.unc.edu>
  6. Date: 8 Sep 92 17:20:26 GMT
  7. References: <REXXLIST%92090516060285@UGA.CC.UGA.EDU>
  8.     <MARTINC.92Sep7194817@grover.cs.unc.edu>
  9.     <1992Sep8.155436.1@sejnet.sunet.se>
  10. Sender: news@cs.unc.edu
  11. Organization: UNC Department of Computer Science
  12. Lines: 53
  13. In-reply-to: eric@sejnet.sunet.se's message of 8 Sep 92 15:54:36 GMT
  14.  
  15. In article <1992Sep8.155436.1@sejnet.sunet.se> eric@sejnet.sunet.se (Eric Thomas) writes:
  16.  
  17.    > I think I should direct you to the note where I went over precisely what
  18.    > I meant using regular expressions.
  19.  
  20.    Did you read your own note? I am getting the impression you are replying to
  21.    the wrong message by mistake.
  22.  
  23.    > But I think your example is flawed:
  24.  
  25.    My examples are not flawed. I have written enough REXX code to know
  26.    what a simple PARSE clause like the ones I quoted above does, if you
  27.    don't believe me feel free to run them through your favourite
  28.    interpreter. 
  29.  
  30. Then you should know enough about rexx code to answer my questions,
  31. shouldn't you?
  32.  
  33.    As you said (and if I ever said the opposite I'd like
  34.    you to show me where), PARSE does indeed strip both leading and
  35.    trailing blanks from the first N-1 variables in a word parsing
  36.    clause. That is precisely why you will lose column positioning if you
  37.    use this form of parsing, as arbitrary amounts of blanks (or
  38.    whitespace in your proposal) are silently eaten up. The only way you
  39.    can remember what columns things were at is if you don't use this
  40.    form of the PARSE statement, in which case it is totally immaterial
  41.    whether or not it treats tabs as whitespace when parsing by word,
  42.    since you won't be parsing by word, and again the conclusion is that
  43.    having this behaviour does not help you in cases where you have:
  44.  
  45.    >    > repeated applications of parse, say with columnar fields.
  46.  
  47. Let me see -- parse for words *does* eat up all the intervening blanks
  48. (pretty much what I expect), does lose column positioning, and blanks
  49. are word separators in a words clause.  It really appears as if you
  50. either 
  51.  
  52. (a) really think that "a<tab>b" ought to be a "word" in the
  53. words-clause sense -- which seems massively counter-intuitive -- or 
  54.  
  55. (b) that you agree sensible behavior is that any whitespace character
  56. NOT OTHERWISE INTERPRETED (like newline) ought to be a word separator.
  57.  
  58. If (a), I'd really like to see it defended.  It seems a massive flaw.
  59. --
  60. Charles R. Martin/(Charlie)/martinc@cs.unc.edu/(ne crm@cs.duke.edu) 
  61. O/Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
  62. H/3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
  63. ----------------------------------------------------------------------
  64. "I am he who walks the States with a barb'd tongue, questioning every
  65. one I meet,/Who are you that wanted only to be told what you knew
  66. before?/ Who are you that wanted only a book to join you in your
  67. nonsense?"  _Leaves of Grass_ xxiii.4.
  68.