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

Internet Message Format | 1992-09-08 | 3.6 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:58:33 GMT
References: <[e-mail]>
    <[e-mail]>
    <[e-mail]>
Sender: [e-mail]
Organization: UNC Department of Computer Science
Lines: 67
In-reply-to: [e-mail]'s message of 7 Sep 92 19:12:17 GMT

In article <[e-mail]> [e-mail] (Eric Thomas) writes:

   In article <[e-mail]>, [e-mail] (Charles R. Martin) writes:
   > I think the contention is that
   >
   > parse arg a b c
   >
   > ought to be a synonym for
   >
   > parse upper arg with a<<\b|\t>+>b<<\b|\t>+>c
   >
   > Now if we had that, I don't see immediately what the need for parse
   > expand would be;

   Conversely, given PARSE EXPAND I don't see what the need for changing
   the definition of all functions which deal with words,
   leading/trailing blanks and so on would be. Compatibility with prior
   applications is guaranteed, and the language only needs to be changed
   in one place.

But as I noted before, if the reg exp syntax is a strict extention, then
there shouldn't be any affect on exsiting functions.  (In fact, having a
reg exp extention might be the answer to the non-IBM world's problems
with parse expand.)

But, tell me -- is parse expand actually part of rexx already?  I can't
seem to find it in the documentation I have.  Are we in a battle of the
competing extentions, or is it already part of usual rexx?

   > in fact, given that the simple identity doesn't hold
   > after parse expand, maybe the whole idea is broken.

   PARSE does not respect identity when using word parsing (ie PARSE
   something A B as opposed to column or literal string parsing),
   because it quietly removes an arbitrary amount of blanks. The only
   case where identity is preserved is when you do not use word parsing.
   This is true regardless of the definition you use for white space.

Then what's the objection to making whitespace remove an arbitrary
number of blanks and tabs?  What existing programs does it break?

   > But the idea of embedded general regular expressions in parse is such a
   > nice one, and seems like such a natural extension to the existing parse,
   > that I think it ought to be seriously considered.

   > parse upper arg with a<<\b|\t>+>b<<\b|\t>+>c

   Nice? Natural? I see.

If you don't like the syntax, well, I never claimed that this was good
syntax.  (Of course, you've elided the part where I said that.)  As far
as it's niceness and naturalness, it is at least nice and natural to
anyone with a competent education in computer science; since (as I said
and you elided again) the point of the notation was to make precise a
concept that had up to then been imprecise, I don't see an objection;
and if the notation used for reg exps is nicely done, those who don't
want to have to deal with such a complicated idea as regular sets can
just ignore them.
--
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.