NetNews Usenet Archive 1992 #20/NN_1992_20.iso/spool/comp/lang/rexx/938

Internet Message Format | 1992-09-08 | 2.8 KB

Path: sparky!uunet!mcsun!uknet!comlab.ox.ac.uk!imc
From: [e-mail] (Ian Collier)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Message-ID: <[e-mail]>
Date: 8 Sep 92 15:49:09 GMT
References: <[e-mail]> <[e-mail]> <[e-mail]>
Organization: Oxford University Computing Laboratory, UK
Lines: 48
X-Local-Date: Tuesday, 8th September 1992 at 4:48pm BST
Originator: [e-mail]

In article <[e-mail]>, [e-mail] (Sam Drake) wrote:
>Excuse me, I'm late to this debate, and frankly the discussion here is
>seriously in the ditch.

Yes, I've joined this argument halfway through as well, and have already
read rather a lot of repetitive articles on the subject.  However, here I go
as well...

I have an interest in this subject (and several other threads too), since -
as you may know - I just released a Unix Rexx version in which the only
whitespace character is '20'x (except that unquoted tabs count as whitespace
when reading in the Rexx source).  While I can see that having PARSE and
WORDPOS treat spaces and tabs identically can have its advantages, I would
much rather leave the language unchanged except for a new builtin function
expand() which expands tabs into spaces (however if there really is demand
for a "PARSE EXPAND <source> <pattern>", having identical meaning to
"PARSE VALUE expand(<source>) WITH <pattern>" then I would reluctantly put
it in).

The following question raises a worry about having PARSE treat tabs as
spaces by default:

>Can someone, calmly, explain for my own edification what's wrong with:
[the following by [e-mail] (Charles R. Martin)]
>>line='foo     bar     bletch' /* that's <space><tab> */
>>parse var line a b c
>>
>>it makes sense to have a='foo', b='bar', and c='bletch', and to have
>>parse eat both whitespace characters just as it already eats any string
>>of blanks between non-blank maximals.

Firstly, PARSE eats only one whitespace character from the last token (i.e.
that assigned to c in the example) - so c would contain at least one
whitespace character after the above parse.

Secondly, if PARSE is supposed to eat exactly one space, what happens if a
tab separates the penultimate token from the last one?  Does it eat the
whole tab, or eat one space from the tab and leave seven still there?

A different point is this: the meaning of "parse value expand(a) with c 15 d"
is clear, but what would "parse var a c 15 d" do if a contains tabs, and
tabs are special to the parse instruction?  Something that starts in column
15 will not necessarily start with the 15th character: in "\t12345678", the
string "78" starts in column 15, but "7" is only the eighth character.  Is
parse allowed to split up a tab character if it spans columns 9-16?

Ian Collier
[e-mail] | [e-mail]