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

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

Path: sparky!uunet!gatech!concert!borg!news_server!martinc
From: [e-mail] (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Message-ID: <[e-mail]>
Date: 7 Sep 92 23:48:17 GMT
References: <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Organization: UNC Department of Computer Science
Lines: 61
In-reply-to: [e-mail]'s message of 7 Sep 92 16:30:41 GMT

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.  But I think your example is flawed:
once again I don't have a rexx interpreter I trust at hand -- by the
way, OS2 2.0 rexx doesn't recognize the expand clause at all, where does
it come from? -- but would you expect the clause

    parse var b c d

to put leading blanks onto the value that shows up in c?  That is, given
b='\b\bX\bY' would you expect c to be "\b\bX"?  That doesn't seem to be
the behavior I have seen so far.
--
Charles R. Martin/(Charlie)/[e-mail]/(ne [e-mail])
O/Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
H/3611 University Dr #13M/Durham, NC 27707/[phone]
----------------------------------------------------------------------
"I am he who walks the States with a barb'd tongue, questioning every
one I meet,/Who are you that wanted only to be told what you knew
before?/ Who are you that wanted only a book to join you in your
nonsense?"  _Leaves of Grass_ xxiii.4.