HDTenEightyP/NetNews huggingface dataset:
From: imc@comlab.ox.ac.uk (Ian Collier)
Newsgroups: comp.lang.rexx
Subject: Re: Regular expression syntax
Date: 8 Sep 92 16:12:49 GMT
Organization: Oxford University Computing Laboratory, UK
X-Local-Date: Tuesday, 8th September 1992 at 5:12pm BST
Originator: imc@msc2.comlab

In article <19920908084344SEB1525@MVS.draper.com>, SEB1525@MVS.draper.com (Steve Bacher) wrote:
>Now that the idea has been seriously suggested, why don't we try to
>come up with a nice REXXy syntax for regular expressions?

>How about this to kick off a discussion...

> Unix-style regexp                Proposed REXX-style expression
>
>  abc                             "abc"
>  a.c                             "a" ANY "c"
>  a*                              ZERO_OR_MORE("a")
>  a.*                             "a" ZERO_OR_MORE(ANY)
>  a[bc]d  (them's sq. brackets)   "a" ("b" OR "c") "d"
>  ^abc                            BEGIN "abc"
>  abc$                            "abc" END

Sorry, but I don't think this is "REXXy".  Apart from anything else,
ZERO_OR_MORE("a"), as well as being rather too verbose IMHO, looks like a
function call but isn't.  What kind of animal is it anyway? (note, I'm not
asking what it does, but what "part of speech" it is in Rexx).

Remember, we do already have some symbols, notably & (and) and | (or).
That's not to say that I would prefer ".+" over any other method of notating
"one arbitrary character or more", however, just that I don't think you are
justified in using "OR" as a reserved word in patterns.

>Then we could have a function MATCH(string,pattern) where pattern
>is a regexp as above.  And we could have PARSE PATTERN pattern WITH...

I'd prefer to limit regular expressions to builtin functions, if we are to
have them at all, really.  Anyway, we might have trouble with the PARSE
syntax if we were to want to know which character represented the "." and
".*" in "foo. .*blah".

I think we are (mainly) wanting to provide regular expressions for unix
users who are familiar with them.  I've programmed in Rexx for years and
never wanted one (though I have used them in other contexts, e.g. in awk).
Therefore I suggest that a syntax familiar to those users (e.g. in the
style of "egrep" et al, but certainly not emacs!) be used, rather than an
artificially Rexx-ized version.  It may not seem particularly obvious to you
to type something like

  call match input,"foo(.) (.*)blah$","x","y"            [*]

but I'm sure the unix-types will love it (no disrespect, of course). ;-)

Ian Collier
Ian.Collier@prg.ox.ac.uk | imc@ecs.ox.ac.uk

[*] In this example, the first parameter is the string to be matched, the
second parameter is the regular expression, and the subsequent parameters
are the names of variables to be assigned with the substrings which matched
parenthesised expressions in the pattern, namely "." and ".*" respectively.
Some value indicating the amount of success of the match will probably be
returned from the function.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sun, 6 Sep 1992 17:56:46 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              6 Sep 1992 22:39:49 GMT from <martinc@GROVER.CS.UNC.EDU>

Could you show the code you find to be unobvious as to interpretation?

PARSE EXPAND VALUE 'abtcd' WITH what?

To me this means (assuming in the particular OS that abtcd is the same
as ab      cd  (tab to column 9)

PARSE EXPAND VALUE 'ab      cd' WITH the same thing.     Dave
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Thu, 10 Sep 1992 09:12:58 EST
From:         KMitra <KMITRA@CCVM.WCUPA.EDU>
Subject:      Looking for a solution
Comments: To: rexxlist%ohstvma.bitnet@pucc.princeton.edu

Hi,
   I have developed a menu system using REXX and have been succesful in pluggin
g all the holes so that the user cannot break out of the system and start looki
ng at the files.  The only problem I could not find a solution is to if a user
breaks out using the <ESC> follewed by the <,>(comma) key. The users are using
PS/2's and the communication protocol is YTERM.  I am wondering if someone out
there knows the solution to this problem.  Thanks in advance.
                                                              KMitra
From: zjlc12@hou.amoco.com (Jerry Campbell)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 8 Sep 92 18:15:52 GMT
Reply-To: zjlc12@hou.amoco.com
Organization: Amoco

An observation and a what if.   Observation, since there is so much controversy
regarding this issue I'd think that would be a clear sign that it should be left
alone.  The programmer should worry about this white space vs. "real" blanks
thing.  What if,  I really, really did want to discriminately parse blanks as
opposed to tabs?  Take a Rexx program that wanted to convert tabs to real blanks
or vice versa?  In this case you would REQUIRE control over the precise value
of the data when parsing.  Please, don't build "intelligent" second guessing
Rexx interpreters.....!   Or standards.

---
Jerry Campbell   reply to: zjlc12@hou.amoco.com 
Amoco Corp. ISD  SSS/Graphics
Houston, Tx.     713/556-7036
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 7 Sep 92 23:41:07 GMT
	<MARTINC.92Sep7104222@grover.cs.unc.edu>
	<1992Sep7.190018.1@sejnet.sunet.se>
Organization: UNC Department of Computer Science
In-reply-to: eric@sejnet.sunet.se's message of 7 Sep 92 19:00:18 GMT

In article <1992Sep7.190018.1@sejnet.sunet.se> eric@sejnet.sunet.se (Eric Thomas) writes:

   In article <MARTINC.92Sep7104222@grover.cs.unc.edu>, martinc@grover.cs.unc.edu (Charles R. Martin) writes:
   > I do rather like the idea of having a syntax for general regular
   > expression matching in parse, though.  (And please don't tell me about
   > how rexx is supposed to be a simple end-user language: people are
   > writing complicated number-theoretic programs and lisp interpreters in
   > rexx.)

   People have a constitutional right to stupidity. 

I'm afraid that a lot of this whole discussion comes out sounding like a
demonstration of this. 

   In my family, screwdrivers generally have a 75% probability of being
   bent because I have never managed to get my relatives to understand
   that they are not designed to be used as levers.  It would be clearly
   more convenient for them if screwdrivers were made much thicker, with
   just the tip being the size of the screw. I'm afraid I don't know any
   hardware company that sells this type of screwdrivers, though.

I don't think this (rather dippy) analogy holds very well.  If parse
were extended with a regular expression syntax that was a strict
extension -- that is, any program which didn't use the reg exp syntax to
get results isn't broken by the addition -- then we'd know that (a) you
can do anything you did before, and (b) that you could do neat new
things.  It's like if someone started making screwdrivers out of a
material with a very high yield point, so that even if you were prying
up a trap door with an elephant on it the shaft would return to shape:
no one would notice that they were any different, except when they tried
to use them as prybars.
--
Charles R. Martin/(Charlie)/martinc@cs.unc.edu/(ne crm@cs.duke.edu) 
O/Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
H/3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
----------------------------------------------------------------------
"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.
From: Leon_Davidoff@panam.wimsey.bc.ca (Leon Davidoff)
Newsgroups: comp.lang.rexx
Subject: Curious Question
Distribution: world
Date: 9 Sep 92 16:17:41 PST
Organization: Commodore Computer Club / PaNorAmA

I whipped up the following code to test something someone was talking 
about in a message.  During my testing I noticed something strange.
 
------------
/* Test1.rexx */
 
Junk = '  x y'
 
parse var Junk a b
 
say a
say b
say c
 
------------
Test1 output: x
               y
              C
------------
/* Test2.rexx */
 
Junk = '  x y'
 
parse var Junk a b c
 
say a
say b
say c
 
------------
 
Test2 output: x
              y
              
 
------------
 
What I would like to know is why b in Test1 is assigned the value ' y'
while in Test2 the value is 'y'.  I think I ran across this problem 
before and I found putting a variable Junk (which I never used) on the 
end of the parse statement made it behave the way I thought it should.
Any ideas?
 
I am using Arexx on a Rejuvenated Amiga 1000 running the 2.04 O/S.
 

-- Via DLG Pro v0.992

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Leon
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Acknowledge-To: <RZOTTO@DKNKURZ1>
Newsgroups: comp.lang.rexx
Date:         Fri, 11 Sep 1992 09:55:05 MEZ
From:         Otto Stolz <RZOTTO@DKNKURZ1.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              9 Sep 92 05:27:26 GMT from <mwm@CONTESSA.PALO-ALTO.CA.US>

In <1992Sep5.134720.1@sejnet.sunet.se>, eric@sejnet.sunet.se (Eric
Thomas) wrote:
> REXX is intrinsically un-unixish:
> identifiers and statements are not case sensitive,
> the language is verbose,
> very few special characters are used,
> strings are not terminated by \0,
> the default value of a variable is its name in UPPER case,
> and so on.

On Wed, 9 Sep 92 05:27:26 GMT Mike Meyer said:
> Personally, the only thing about this list that bothers me is
> variables having a default value. That's because it makes a large
> class of typos hard to find, and I have the same complaint about any
> programming language that has the same design flaw.
>
> That's also the only thing on that list that Rexx does differently
> from my favorite language.

To turn REXX into your favourite language, just include the following two
magic lines with every REXX program you write, or edit:
   signal on novalue
   address none

The former line tells the REXX interpreter to check for un-initialized
variables (effectively catching typos in variable names), the latter
tells it to send the results of bare expressions to an non-existing
environment (effectively catching typos in key-words -- provided there
is actually no active environment that happens to be named "NONE", of
course).

I have made an habit of including those lines with every program, and
they have saved me lots of debugging-time!

Happy programming,
                    Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
                               <RZOTTO@nyx.uni-konstanz.de>
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: NOVALUE (was: Blanks, REXX, and portability...)
Date: 11 Sep 92 02:56:33 GMT
Organization: UNC Department of Computer Science
In-reply-to: bobcook@unixhub.SLAC.Stanford.EDU's message of 11 Sep 92 01:17:32 GMT

In article <5456@unixhub.SLAC.Stanford.EDU> bobcook@unixhub.SLAC.Stanford.EDU (Bob Cook) writes:

   (Somewhat) unfortunately, SIGNAL ON NOVALUE doesn't catch all of the
   uses of an undefined variable.  At least, it doesn't on VM/CMS.  In
   the following piece of code, the "say" statement produces "Hi" on the
   console, even though it uses the variable named X, which has never
   been initialized.

     signal on novalue
     dummy = 'X' 
     a.dummy = 'Hi'
     say a.x
     exit
   Novalue: Say 'Oops'

I'm pretty new at this, but I *think* that's the defined behavior, not a
bug.  Notice that 

	say x
	exit

prints 

	X

to the output stream.  Further notice that

/*     signal on novalue  */
     dummy = 'B' 
     a.dummy = 'Hi'
     say a.x
     say a.b
     exit
   Novalue: Say 'Oops'

prints

	A.X
	Hi

(the signal is commented out because the brain-damaged excuse for a rexx
I've currently got on this system doesn't speak "signal on novalue".
No, Anders, it wasn't regina.)

Anyway, I think it's clear that what is happening is that the stem
reference is "dereferenced" if the RHS of the stem is a variable, but
used directly as a string if not, at least in a "say" clause.
--
Charles R. Martin/(Charlie)/martinc@cs.unc.edu/(ne crm@cs.duke.edu) 
O/Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
H/3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
----------------------------------------------------------------------
"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.
Newsgroups: comp.lang.rexx
From: eric@sejnet.sunet.se (Eric Thomas)
Subject: Re: Blanks, REXX, and portability...
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden
Date: Tue, 8 Sep 1992 16:25:42 GMT

In article <1966@coyote.UUCP>, drake@drake.almaden.ibm.com (Sam Drake) writes:
>>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.  
> 
> I'm just a simple guy, but I can't think of anything wrong with this.
> What's the argument on this point, if any?

Taking the REXX language as it is today (tab et al not treated as whitespace
characters), you cannot implement JUST this one change without breaking
everything. You have to change a bunch of other functions to keep a homogeneous
behaviour. For instance, it is common to code:

Do Words(list)
   Parse var list elm list
   <...>
End

WORDS and PARSE had better agree on how many times to run the loop. Similarly,
WORD must produce the same result in case you read the elements with
WORD(list,i). After doing 'list = Space(list,0)', it is reasonable for the
programmer to assume that Words(list) = 1 (or possibly 0, but surely not 2).
Thus SPACE must be changed as well, and the same goes for STRIP, and so on.
Now, once you have changed STRIP, it is necessary to have (I'll use ASCII)
'09'x = ' ', '0D'x = ' ', etc. That might be a surprise to existing programs.
That's a lot of places to change, too. And still there are things which are not
too easy to do, for instance translating all white space to a blank or some
other character, or expanding tabs. It can be done, but the language won't help
you do this.

The alternative is to add an EXPAND function and enhance PARSE so that

                  PARSE EXPAND something pattern

is equivalent to

                  PARSE VALUE EXPAND(something) WITH pattern

much like PARSE UPPER is equivalent to PARSE VALUE TRANSLATE() WITH. One new
function, which is useful on its own, and one place to change.

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Acknowledge-To: <RZOTTO@DKNKURZ1>
Newsgroups: comp.lang.rexx
Date:         Wed, 9 Sep 1992 16:24:18 MEZ
From:         Otto Stolz <RZOTTO@DKNKURZ1.BITNET>
Subject:      Re: Blanks, REXX, and portability...

On Tue, 8 Sep 92 18:15:52 GMT Jerry Campbell said:
> [...] since there is so much controversy regarding this issue I'd
> think that would be a clear sign that it should be left alone. The
> programmer should worry about this white space vs. "real" blanks thing.

I think much of the controversy is arising from contributors not being
aware what was actually proposed (including Jerry, I am sorry to say).
In any case, a programming language standard simply *cannot* choose to
leave a controversal issue alone -- on the contrary: the sole purpose
of a standard is to settle controversies of this sort (viz. how a
particular feature has to be understood and implemented). As TRL is based
on a faulty assumption (only in this regard), the standard simply
*cannot* incorporate its wording unaltered, or without any consideration.

> What if, I really, really did want to discriminately parse blanks as
> opposed to tabs? Take a Rexx program that wanted to convert tabs to
> real blanks or vice versa? [...]

In this case you would not want to parse your data into words, will you?
Hence, the whole discussion simply does not apply to this case. You
would use positional parsing, or the SUBSTR function, or whatever
character-oriented (as opposed to word-oriented) operation you deem
appropriate to get at the pieces of your data; and you would be well
adviced to use strict comparison operators (even in the CMS implement-
ation, to be sure your program can distinguish zero blanks from one
blank).

> Please, don't build "intelligent" second guessing Rexx inter-
> preters.....!   Or standards.

Agreed! But this guideline does not preclude intelligent (without
quotes!), consistent, standrad-conforming, and usable interpreters.
Or standards. That's what I think I have proposed, btw.

Happy programming,
                    Otto Stolz <RZOTTO@DKNKURZ1.Bitnet>
                               <RZOTTO@nyx.uni-konstanz.de>
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Best way to handle arrays and structures in rexx
Date: 15 Sep 92 17:15:26 GMT
Distribution: comp
Organization: UNC Department of Computer Science

Say I want to implement a parser that constructs a tree using rexx.  How
would I best represent the tree?

Seems like the following schemes would work:

Put each node of the tree into an array, i.e. a new operation would use
a node count and build the new node using 

	ary.nodecount = /* some nice node initialization */

Now the data in each node would be some kind of record representing the
node, and it seems there are two ways of doing that -- either I can
assign a string to ary.nodecount and parse that string into its
constituent fields when I need them, or I can build a futher qualified
name onto the ary.ix stem, like ary.ix.left = /* index of the left
child */.

Some questions:

1. Other than the parsing time, is there any reason to prefer one over
the other (like, for example, you can't have two '.'s in a name, so
a.b.c would be a syntax error)?

2. I understand that it's common conventionally to keep the size of an
array as ary.0 (although I'd probably prefer ary.size or ary.card it I
were using numeric indices.)  Can I write some expression like

	ary.(ary.0) = ...

to refer to that value directly?

The second approach I've thought of is to generate a new name for
each vertex, then use the stem construction for the fields in that
vertex.  (Although that appears to be very much like using the stem
construction.)  Any advantage to that?

And of course, there is always the chance that there are a third fourth,
etc, way of doing it that is both reasonably efficient -- although
efficiency isn't my main concern, since if it were I'd write in C -- and
for some reason better than there.

I'd appreciate any information you-all can offer.

--
Charles R. Martin/(Charlie)/martinc@cs.unc.edu/(ne crm@cs.duke.edu) 
O/Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
H/3611 University Dr #13M/Durham, NC 27707/(919) 419 1754
----------------------------------------------------------------------
"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.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sat, 12 Sep 1992 07:51:21 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: NOVALUE (was: Blanks, REXX, and portability...)
              12 Sep 1992 01:18:34 GMT from <bobcook@UNIXHUB.SLAC.STANFORD.EDU>

On Sat, 12 Sep 1992 01:18:34 GMT Bob Cook said:
>That is exactly the point that I'm commenting upon.  I have been bitten by
>introducing a hard-to-find bug because a reference to "a.x", where x was meant
>to be a variable, instead treated the x as a constant because the variable x
>had (mistakenly) never had a value assigned.

Wait, if you intended to have x have the value 123 but by mistake it was
undefined, then are you saying that just by lucky accident a.x WAS defined?
That streches my credulity some.  And I would assume that you caught it on
the second run with trace.  I am pretty unimpressed by this unassigned
variable stuff.  FORTRAN may be nearly the world's worst language, but it
does teach you to initialize variables when failure to do so brings down
a multiuser operating system (MFT).   Dave
Newsgroups: comp.lang.rexx
Subject: Expressions in compound variables (was Re: NOVALUE)
From: Linda Littleton <LRL@psuvm.psu.edu>
Date: Mon, 14 Sep 1992 17:13:16 EDT
Organization: Penn State University

In article <REXXLIST%92091210585300@UGA.CC.UGA.EDU>, Dave Gomberg
<GOMBERG@UCSFVM.BITNET> says:

>On Sat, 12 Sep 1992 06:22:02 GMT Paul Gilmartin said:
>>   say a.(substr('UVWXYZ',4,1))   /* Why not, haven't you wanted it? */
>>
>>Is anyone proposing this extremely desirable extension?

>When the SHARE REXX committee debated this "extension" at great length,
>it turned out to be next to impossible to define.

Dave, Maybe you're remembering a different discussion than I do.  SHARE
did put in a requirement for this back in 1989.  I think it is a useful
extension and would reduce the "astonishment factor" new users have when
they find that things like this (especially simpler things like x.(y+1))
don't work.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Tue, 15 Sep 1992 09:21:23 EDT
From:         Kent Fiala <SNOKLF@VM.SAS.COM>
Subject:      Re: Relaxing of argument-passing restriction?
Comments: To: General REXX Discussion List
              <REXXLIST@OHSTVMA.ACS.OHIO-STATE.EDU>
              15 Sep 1992 01:25:21 EDT from <ophof@SERVER.UWINDSOR.CA>

On Tue, 15 Sep 1992 01:25:21 EDT Scott Ophof said:
>A definite improvement of REXX would be to define the number of
>passable argument strings AT THE COMMAND-LINE LEVEL to be
>implementation-dependant.  Calls to internal subroutines & built-in
>functions are not subject to this limit.

In REXX it's unambigous that the statement

   call gem arg1, arg2

passes two arguments, and that the statement

   call gem 'arg1, arg2'

passes one argument.  How would you implement the same distinction
at the command-line level?

------------------------------------------------------------------------
Kent Fiala <snoklf@vm.sas.com>
SAS Institute Inc., Cary NC 27513 USA                 919-677-8000 x6646
Newsgroups: comp.lang.rexx
From: anders@lise1.lise.unit.no (Anders Christensen)
Subject: Re: REXX on UNIX?
Organization: University of Trondheim, Norway
Date: 8 Sep 92 22:32:39

In article <1992Sep8.190446.21524@kocrsv01.delcoelect.com> c23mld1@kocrsv01.delcoelect.com (Marc DeWever) writes:

> Are there any public domain implementations of REXX available for 
> Unix systems, and if so where can they be found?

No, there are no Public Domain implementation of REXX, as far as I know. 

There are, however, at least three 'free' implementations of REXX for
Unix. 'Free' in the sense that they are obtainable by anonymous ftp at
no cost (other than what you ... or your university/company ... pay
for the network connection).

They can be obtained by anonymous ftp from "rexx.uwaterloo.ca" in the
directory "pub/freerexx" (or something similar).

-anders
From: anders@lise1.lise.unit.no (Anders Christensen)
Subject: Re: Blanks, REXX, and portability...
Organization: University of Trondheim, Norway
Date: 9 Sep 92 13:09:30

In article <9209081750.AA03265@lns598.TN.CORNELL.EDU> cultural elite <dsr@LNS598.TN.CORNELL.EDU> writes:

>                             However, Eric may have come up with a serious
> objection with his argument that this implies '\t' = ' ' be true, which
> I'm not entirely happy about.

Why are you not happy with that? What about  ' ' = '  '  or  ' ' = '' 
Both of these are also true. If you want leading and trailing 'blanks'
to matter, you should use strict comparisation, like:  '\t' == ' '.

-anders