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

Text File | 1992-09-08 | 4.0 KB | 83 lines

Newsgroups: comp.lang.rexx
Path: sparky!uunet!mcsun!sunic!sejnet.sunet.se!eric
From: [e-mail] (Eric Thomas)
Subject: Re: Blanks, REXX, and portability...
Message-ID: <[e-mail]>
Lines: 70
Sender: [e-mail]
Reply-To: [e-mail]
Organization: SUNET, Stockholm, Sweden
References: <[e-mail]> <[e-mail]>
Date: Tue, 8 Sep 1992 15:54:36 GMT

In article <[e-mail]>, [e-mail] (Charles R. Martin) writes:
> In article <[e-mail]> [e-mail] (Eric Thomas) writes:
>
>    In article <[e-mail]>, [e-mail] (Charles R. Martin) writes:
>    > I think the problem lies in repeated applications of parse, say with
>    > columnar fields.  Say I parse the string "ab\tc" -- importing a little C
>    > terminology to make clear where the tab lies -- with parse expand.  The
>    > tab char should come out to be some number of blanks, as I understand
>    > it. (Probably 6 for canonical tabs.)  But if I parse off the first
>    > field, THEN parse the resulting "\tc", the tab now wants to expand to 8
>    > characters.
>
>    Good point, but this is a hasty conclusion. IF you are worried about exact
>    column positions and have to cope with data containing tabs and blanks, you
>    will have to think carefully in any case. As you pointed out,
>
>                    Parse var line a +2 b
>                    Parse expand var b <whatever>
>
>    will not work, but
>                    Parse expand var line a +2 b
>                    Parse var b <whatever>
>
>    does what you want. If you expand, you have to expand at the source.
>    Now, with a REXX that has built-in white space recognition rather
>    than expand, the code fragment would have to be:
>
>                    Parse var line a +2 b
>                    Parse var b <whatever>
>
>    The first PARSE gives you a variable 'b' that starts with a tab, the
>    second PARSE throws it away (since it is white space) unless you use
>    columnar or pattern based parsing. Losing the tab will surely screw
>    up your column positioning, since it will yield exactly the same
>    result as if the tab had been a blank. So the only way to handle this
>    situation properly is to use a form of parsing which does NOT treat
>    tabs as white space. You are not making use of the interpreter's
>    automatic handling of tabs.
>
>    In other words, the situation is not better with a REXX that
>    automatically treats tabs as white space; in fact, it is worse.
>
> I think I should direct you to the note where I went over precisely what
> I meant using regular expressions.

Did you read your own note? I am getting the impression you are replying to
the wrong message by mistake.

> But I think your example is flawed:

My examples are not flawed. I have written enough REXX code to know what a
simple PARSE clause like the ones I quoted above does, if you don't believe me
feel free to run them through your favourite interpreter. As you said (and if I
ever said the opposite I'd like you to show me where), PARSE does indeed strip
both leading and trailing blanks from the first N-1 variables in a word parsing
clause. That is precisely why you will lose column positioning if you use this
form of parsing, as arbitrary amounts of blanks (or whitespace in your
proposal) are silently eaten up. The only way you can remember what columns
things were at is if you don't use this form of the PARSE statement, in which
case it is totally immaterial whether or not it treats tabs as whitespace when
parsing by word, since you won't be parsing by word, and again the conclusion
is that having this behaviour does not help you in cases where you have:

>    > repeated applications of parse, say with columnar fields.

Now if you would please run further examples through an interpreter so that you
can come up with concrete situations where there is indeed a problem, we would
all save a lot of time.

  Eric