home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #19 / NN_1992_19.iso / spool / comp / lang / rexx / 828 < prev    next >
Encoding:
Text File  |  1992-08-29  |  3.2 KB  |  63 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: Blanks vs white space...
  5. Message-ID: <1992Aug29.170232.1@sejnet.sunet.se>
  6. Lines: 50
  7. Sender: news@sunic.sunet.se
  8. Reply-To: ERIC@SEARN.SUNET.SE
  9. Organization: SUNET, Stockholm, Sweden
  10. References: <ANDERS.92Aug29050537@lise3.lise.unit.no>
  11. Date: Sat, 29 Aug 1992 17:02:32 GMT
  12.  
  13. Frankly, I am a bit surprised at the sheer amount of bytes of arguments,
  14. proposals and counter-proposals that this fairly simple "blanks and whitespace"
  15. problem has generated. Personally I can't see what is so complicated about it
  16. that requires proposals of more than 200 lines which touch about each and every
  17. function in the language, and what is so controversial about making it easier
  18. for unixers to process tabs et al the way they are used to - without breaking
  19. anything, of course.
  20.  
  21. It is a fact that most non-EBCDIC systems use tabs in source code, and won't
  22. change their minds just because of REXX. So REXX interpreters running on ASCII
  23. systems should accept tabs as valid white space delimiters in source code. That
  24. is, if I enter a tab rather than 8 spaces before "Do i = 1 for 10", it should
  25. make no difference to the interpreter. Anything else will cause trouble to the
  26. end users, especially those who don't know the magic formula to tell vi to
  27. expand tabs.
  28.  
  29. A tab in a comment is obviously ignored, just like a blank in a comment or a
  30. W in a comment. I can't believe this issue was even raised!
  31.  
  32. A tab in a quoted string is a tab, not a blank, just like in C and other unix
  33. languages. Programmers will probably avoid putting tabs in quoted strings,
  34. because they look like blanks when editing the file. In C they would use \t, in
  35. REXX I guess they will code '09'x. I don't see any problem here.
  36.  
  37. When I ask the REXX interpreter to locate a string containing a blank, either
  38. via PARSE or POS or other similar function, I probably really mean blank, not
  39. white space. Even if I did mean white space, I would be making a major mistake
  40. in assuming that the blank I type should be interpreted as white space: one of
  41. the cornerstones of REXX is that you can manipulate strings of any length and
  42. containing any possible character, from 00 to FF. If blank in a literal means
  43. "any white space will match", there is no way to search binary data for
  44. something which contains a genuine blank, and this is obviously a very serious
  45. problem. So we keep PARSE and built-in functions exactly as they are today.
  46.  
  47. To solve the problem of system commands which return tabs and files which
  48. contain tabs and have to be parsed as words, we add a very powerful, very
  49. complicated built-in function, the type which takes hours to master:
  50.  
  51.                                   expand(x)
  52.  
  53. This function expands tabs, throws away the square-root-of-pi-div-2-emm-space
  54. characters in the latest lame excuse for nice business trips the ISO came up
  55. with, and returns something which can be directly used with all the usual PARSE
  56. and POS functions. One might want to add an optional parameter or two to
  57. specify the tab columns and whether non-linear white space characters such as
  58. CR/LF should be translated to blanks or left intact, but you get the picture.
  59.  
  60. My turn to be flamed now :-)
  61.  
  62.   Eric
  63.