home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / lang / rexx / 924 < prev    next >
Encoding:
Text File  |  1992-09-08  |  1.7 KB  |  48 lines
  1. Newsgroups: comp.lang.rexx
  2. Path: sparky!uunet!mcsun!sunic!sejnet.sunet.se!eric
  3. From: eric@sejnet.sunet.se (Eric Thomas)
  4. Subject: Re: Blanks, REXX, and portability...
  5. Message-ID: <1992Sep7.191217.1@sejnet.sunet.se>
  6. Lines: 35
  7. Sender: news@sunic.sunet.se
  8. Reply-To: ERIC@SEARN.SUNET.SE
  9. Organization: SUNET, Stockholm, Sweden
  10. References: <REXXLIST%92090701365930@UGA.CC.UGA.EDU> <MARTINC.92Sep7110759@grover.cs.unc.edu>
  11. Date: Mon, 7 Sep 1992 19:12:17 GMT
  12.  
  13. In article <MARTINC.92Sep7110759@grover.cs.unc.edu>, martinc@grover.cs.unc.edu (Charles R. Martin) writes:
  14. > I think the contention is that
  15. > 
  16. > parse arg a b c
  17. > 
  18. > ought to be a synonym for 
  19. > 
  20. > parse upper arg with a<<\b|\t>+>b<<\b|\t>+>c
  21. > 
  22. > Now if we had that, I don't see immediately what the need for parse
  23. > expand would be;
  24.  
  25. Conversely, given PARSE EXPAND I don't see what the need for changing the
  26. definition of all functions which deal with words, leading/trailing blanks and
  27. so on would be. Compatibility with prior applications is guaranteed, and the
  28. language only needs to be changed in one place.
  29.  
  30. > in fact, given that the simple identity doesn't hold
  31. > after parse expand, maybe the whole idea is broken.
  32.  
  33. PARSE does not respect identity when using word parsing (ie PARSE something A B
  34. as opposed to column or literal string parsing), because it quietly removes an
  35. arbitrary amount of blanks. The only case where identity is preserved is when
  36. you do not use word parsing. This is true regardless of the definition you use
  37. for white space.
  38.  
  39. > But the idea of embedded general regular expressions in parse is such a
  40. > nice one, and seems like such a natural extension to the existing parse,
  41. > that I think it ought to be seriously considered.
  42.  
  43. > parse upper arg with a<<\b|\t>+>b<<\b|\t>+>c
  44.  
  45. Nice? Natural? I see.
  46.  
  47.   Eric
  48.