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