HDTenEightyP/NetNews huggingface dataset:
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 9 Sep 92 13:59:55 GMT
Organization: UNC Department of Computer Science
In-reply-to: dsr@LNS598.TN.CORNELL.EDU's message of 8 Sep 92 17:50:26 GMT

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

   But anyway, I'm not advocating that tabs and blanks be made generally
   synonymous--all I want is for them to both be accepted as word separators
   in parse, word(), words(), and a few other obvious places, which does not
   imply general synonymy.  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.

Hmm.  I must have missed that -- can someone explain why tab being
whitespace implies '\t' = ' ' has to be true?
--
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: GOMBERG@UCSFVM.BITNET (Dave Gomberg)
Newsgroups: comp.lang.rexx
Subject: Re: NOVALUE (was: Blanks, REXX, and portability...)
Date: 12 Sep 92 14:56:05 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
              12 Sep 1992 06:13:53 GMT from <GILMART@LSTC2VM.STORTEK.COM>

On Sat, 12 Sep 1992 06:13:53 GMT Paul Gilmartin said:
>if the NOVALUE: procedure doesn't exist.  And if I supply the NOVALUE:
>procedure, 370 interpreted Rexx doesn't give the nice call traceback that's
>so precious for debugging.

Are we really asking for a SNAP bif then?   x=SNAP() returns 0 and writes
a snapshot trace to the error output device?
Newsgroups: comp.lang.rexx
From: exukjb@exu.ericsson.se (ken bell)
Newsgroups: comp.lang.rexx
Subject: Re: newbie rexx programmer asks silly questions
Date: 9 Sep 92 19:24:32 GMT
Organization: Ericsson Network Systems, Inc.

In article <920904.171408.CDT.MARK@RICEVM1.RICE.EDU> MARK@RICEVM1.RICE.EDU (Mark R. Williamson) writes:
>From: MARK@RICEVM1.RICE.EDU (Mark R. Williamson)
>Subject: Re: newbie rexx programmer asks silly questions
>Date: 4 Sep 92 22:14:08 GMT

>On Fri, 4 Sep 1992 09:56:01 PDT Dave Gomberg said:
>>What, please, is the Programmer's Shop Catalog?

>It is a catalog of DOS, Windows, OS/2, and Unix tools for programmers,
>published by The Programmer's Shop; 90 Industrial Park Road; Hingham,
>MA 02043; 1-800-421-8006; 1-617-740-2017; FAX 1-617-740-4233 or -1872.
>They also have branches in Germany and Italy.  The catalog is 188pp in
>it's most recent incarnation, which just happened to be on top of my
>stack of recent incoming mail.

>I've never ordered anything from them.  (They don't do Macs or mainframes,
>which is where I do most of my work.)  Now I know why I didn't toss it out.

>Mark R. Williamson, Rice U., Houston TX; MARK@RICEVM1.RICE.EDU or @RICEVM1

Has anyone out there in REXX land used Rudner's REXXTOC which translates 
rexx code to C souce? 
------------------------------------------------------------------------------
Kenny Bell                          *        Welcome to Mind Wars
Ericsson Network Systems, Inc       *        ANTHEM BBS 386-7907
P.O. Box 833875                     *        Severity with oneself is heroism.
Richardson, TX 75083-3875           *        --A.G.Sertillanges (France, 1943)
------------------------------------------------------------------------------
Newsgroups: comp.lang.rexx
From: mcampbel@ocoee (Mike Campbell )
Subject: compound variable question
Organization: University of Central Florida
X-Newsreader: Tin 1.1 PL4
Date: Tue, 15 Sep 1992 15:53:13 GMT

Is there any way to 'remember' the indices used in compound variables?

i.e., I have some rexx code that gathers words from a text file, 

then, I do this:

count.word = count.word + 1

where 'word' the actual word having been gotten.  The upshot of this is
that the 'count' array ends up looking like:

count.'if' = 3
count.'then' = 2
count.'anything_else' = 1

etc.

Is there any way to go through the indices of count, without having to
specifically keep track of the words used as the indices?

(Similar to awk: for (index in array) {} type of thing...)


Newsgroups: comp.lang.rexx
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: regina bug with very long strings
Organization: Draper Laboratory
Date: Tue, 8 Sep 1992 22:02:00 GMT

There appears to be a bug in Regina 0.03d with long strings.
If I do something like

 foo = copies("x",100000)

and then do

 say length(foo)

I get a segmentation fault.  Where exactly the fault occurs depends on
if I run the SunOS version or the AIX version.

Similarly, if I do

foo = 'cat'('/etc/hosts')

(which produces a very long string for most people)

on SunOS, length(foo) returns a negative number; on AIX, the operation
gets a segmentation fault.

This is triggered by any attempt to create a string longer than
32767 bytes.

Shouldn't Regina recover more gracefully from attempts to create a
string longer than the maximum value it can handle?  Is this maximum
value documented, anyhow?  It would be less painful if the length of a
string were held as an int rather than a short (see src/strings.h).

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 6 Sep 92 22:34:14 GMT
Organization: UNC Department of Computer Science
In-reply-to: GOMBERG@UCSFVM.BITNET's message of 5 Sep 92 19:48:38 GMT

In article <REXXLIST%92090515552695@UGA.CC.UGA.EDU> GOMBERG@UCSFVM.BITNET (Dave Gomberg) writes:

   On Sat, 5 Sep 1992 17:50:20 GMT Charles R. Martin said:
   >1. I don't think any sensible interpretation of pos('a b'...) would
   >   permit it to match on either 'a<blank>b' or 'a<tab>b'.  I'd certainly
   >   consider such an implementation buggy.

   I am glad I don't run an implementation you wrote.  I would sue an
   implementer who would ever return something besides 1 from pos(x,x),
   even if x had blanks in it (unless, of course, x was the null
   string).  Why would they even matter?  Have you read the definition
   of pos?

Um, are you sure that you read what *I* wrote?  In English, "either ...
or" is *inclusive* or.  What I said is that I would be displeased by an
implementation of pos which matched "a b" with either "a<space>b", OR
"a<tab>b".  In other words, I'd expect pos("a b", "a b") to return 1 and
pos("a b","a	b") (that's a tab character in there) to return 0.


--
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
X-Acknowledge-To: <U632111@HNYKUN11>
Newsgroups: comp.lang.rexx
Date:         Fri, 11 Sep 1992 09:18:30 MET
From:         "W. J. Metzger" <U632111@HNYKUN11.BITNET>
Subject:      Re: REXXShip 2.2
              10 Sep 92 17:04:29 GMT from <sip1@ELLIS.UCHICAGO.EDU>

I tried your file on CMS.  It ran into problems because the functions
STREAM, CHARS, and CHAROUT are not known (perhaps there are also other
difficulties).
From: imc@comlab.ox.ac.uk (Ian Collier)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 8 Sep 92 15:49:09 GMT
Organization: Oxford University Computing Laboratory, UK
X-Local-Date: Tuesday, 8th September 1992 at 4:48pm BST
Originator: imc@msc2.comlab

In article <1966@coyote.UUCP>, drake@drake.almaden.ibm.com (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 martinc@grover.cs.unc.edu (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
Ian.Collier@prg.ox.ac.uk | imc@ecs.ox.ac.uk
From: GILMART@LSTC2VM.stortek.com (Paul Gilmartin)
Newsgroups: comp.lang.rexx
Subject: Re: NOVALUE (was: Blanks, REXX, and portability...)
Date: 12 Sep 92 06:13:53 GMT
Organization: StorageTek SW Engineering

In article <19920910194427SEB1525@MVS.draper.com>
SEB1525@MVS.draper.com (Steve Bacher) writes:
 
>If you use SIGNAL ON NOVALUE, you won't have to put up with this.
>IMHO, REXX programmers should *always* use SIGNAL ON NOVALUE unless
>there is a very good reason (obscure hacks included) not to do so.
 
Ah, but they're making it hard for us!  Compiled Rexx and uni-REXX (perhaps
others) report SIGNAL ON NOVALUE as a syntax error _prior_to_execution_
if the NOVALUE: procedure doesn't exist.  And if I supply the NOVALUE:
procedure, 370 interpreted Rexx doesn't give the nice call traceback that's
so precious for debugging.
 
Sigh,
gil
Organization: Queen's University at Kingston
Date: Wednesday, 9 Sep 1992 01:00:08 EDT
From: Jeff Boyd <BOYDJ@QUCDN.QueensU.CA>
Newsgroups: comp.lang.rexx
Subject: Re: Reading inline "code" as input?


The Rexx "sourceline" function seems to be what you need.


jeff
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: Mon, 7 Sep 1992 19:12:17 GMT

In article <MARTINC.92Sep7110759@grover.cs.unc.edu>, martinc@grover.cs.unc.edu (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.

> 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.

> 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.

  Eric
Newsgroups: comp.lang.rexx
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: Regular expression syntax
Organization: Draper Laboratory
Date: Tue, 8 Sep 1992 13:43:00 GMT

Now that the idea has been seriously suggested, why don't we try to
come up with a nice REXXy syntax for regular expressions?

In the REXX tradition, it should be readable:  i.e. wordy and with
minimal use of special characters.

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

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

Maybe we need to separate the pattern elements with commas, or
surround the whole thing in a REGEXP(...) pseudofunction call.
Should patterns be evaluated like other REXX expressions, or
do we need a special syntax for run-time pattern generation
a la parentheses in PARSE?

Well, you get the idea.  Remember, verbosity is not a bad thing
in REXX.  I'm sure that youse can come up with something better
if you try.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 8 Sep 92 17:29:54 GMT
	<1992Sep8.154048.1@sejnet.sunet.se>
Organization: UNC Department of Computer Science
In-reply-to: eric@sejnet.sunet.se's message of 8 Sep 92 15:40:48 GMT

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

   In article <19920907131702SEB1525@MVS.draper.com>, SEB1525@MVS.draper.com (Steve Bacher) writes:
   > At least with the more reasonable proposals,
   > 
   >  PARSE VALUE DIAG(something) WITH var1 var2 '15'x var3 var4 '15'x var5
   > 
   > should continue to work just fine, regardless of whether '15'x is
   > considered whitespace or not.  A correct implementation of REXX will
   > break up the line at the '15'xes and only then perform the whitespace
   > analysis on the resulting pieces.

   Yes, that much will work, and it is indeed what people generally code
   to process the output of commands which produce a fixed-size answer
   (like when extracting the time zone name from QUERY TIME). But there
   are many commands which produce variable-size output that one
   processes in a loop (example: QUERY NAMES). What bothers me is that
   we now have '15'x = ' ', a situation most programmers must NOT have
   quite expected. My own programs would not be affected since I always
   use ==, but the amount of spontaneous religious flames I get about
   this usage from people who have read my code for the first time
   suggests that most programmers do use = and thus their programs would
   break.

Hmmm.  It seems as if there are multiple topics in this, all
confabulated together.

(1) Should newline be considered a whitespace character, or more
   generally should the rexx definition of whitespace be equivalent to
   anything for which unix isspace() returns 1?

I think the answer is "no".  Even other UNIX languages that are line-
oriented (like awk) don't do this.  It's clear that for any language
serving similar purposes to rexx and awk, newline must be distinguished
from Blank, tab, formfeed, VT etc.

(2) Should parse (and WORDS, WORDPOS, etc) be extended or modified to
   make any arbitrary whitespace a word separator?

I've already argued that it is more orthogonal and more uniform to
answer "yes".

(3) Should parse be extended with some kind of general regular
   expression mechAnism?

I think it's worth seriously considering -- before I fell asleep last
night I got thinking about some of the things one could do with an
appropriate rexexp parse, and it's pretty exciting.
--
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: kiehl@ibt013.ibt.kfa-juelich.de (Horst Kiehl)
Newsgroups: comp.lang.rexx
Subject: Re: Reading inline "code" as input?
Keywords: inline, sourceline
Date: 9 Sep 92 11:27:24 GMT
Reply-To: kiehl@ibt013.ibt.kfa-juelich.de (Horst Kiehl)
Organization: Forschungszentrum Juelich GmbH (KFA), Germany

In article <275@zam103.zam.kfa-juelich.de>, I write:

>So you could insert the XXEncoded stuff in a comment in the middle
>of the program, like:
>
>   /* XX:
>   SDFJKGSASD
>   ASDFJASDLD
>   ASDFLASDFL
>   ASDFL
>   */
>
>and locate the line containing ' XX:' by a loop using SOURCELINE.

If the XXEncoded stuff can include REXX comment delimiters
('/*' and '*/'), single or double quotes, you probably have to use a
different method to include it in the REXX program. Apparently the OS/2
REXX interpreter scans the whole program before interpreting it,
detecting any unmatched "/*" or quote. (I don't know if that is demanded
by the language definition.) (Aside, an unmatched "*/", outside
comments, is allowed.) That implies that movine the XX-code (with or
without comment delimiters) to the very end of the program woudn't help
either.
<...+....1....+....2....+....3....+....4....+....5....+....6....+....7....+....>

You might include the XX-code as a literal string (to be used in an
assignment, for example), but the length of literal strings is subject
to an implementation limitation of 250 characters. (Other interpreters
may have different implementation limits.) (Of course, values (as of
variables) may be of any length, or rather, as long as the machine can
handle -- I just expanded my swapfile from 4Mbyte to 34Mbyte by using
COPIES('*', 32*1024*1024) in a test program.)

So apparently you have to ship the XX-code in a separate file (as you
currently do, I suppose).

If anyone else can prove me wrong, please do!

All the best,

Horst
Newsgroups: comp.lang.rexx
From: giguere@csg.uwaterloo.ca (Eric Giguere)
Subject: Re: COMPILER FOR AREXX? HAS ANYBODY TRIED IT??
Organization: University of Waterloo
Date: Sun, 6 Sep 1992 23:47:28 GMT

In article <beman.1d68@terapin.com> beman@terapin.com (Bemis Jarvis) writes:
>I FOUND AN ADVERIZEMENT IN LAST MONTH AMIGA WORLD FOR AN AREXX COMPILER HAS
>ANYBODY TRIED IT.  IT BOAST 15 X FASTER PROGRAMS... LET ME KNOW...THANKS.

Yep, I've tried it.  Wrote a review of it (the REXX Plus compiler) in the
Sept. AmigaWorld.  Good product, integrates cleanly with ARexx.  If you need
more speed, it's a good thing to get.

-- 
 Eric Giguere                                    giguere@csg.UWaterloo.CA
          So is Windows NT short for "Windows, NOT?"  
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: Mon, 7 Sep 1992 16:30:41 GMT

In article <MARTINC.92Sep6183949@grover.cs.unc.edu>, martinc@grover.cs.unc.edu (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.

  Eric
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: Wed, 9 Sep 1992 00:08:26 GMT

In article <MARTINC.92Sep8132026@grover.cs.unc.edu>, martinc@grover.cs.unc.edu (Charles R. Martin) writes:
> Then you should know enough about rexx code to answer my questions,
> shouldn't you?

Don't you have documentation with your interpreter? If not, can't you buy the
REXX book? In any case, if you are unsure of the interaction between columnar,
literal and word parsing, why don't you just ask explicitly before making
assumptions in your examples and making people waste their time showing the
flaw in a point they thought you were trying to make but which turned out not
to be what you meant?

> Let me see -- parse for words *does* eat up all the intervening blanks
> (pretty much what I expect), does lose column positioning, and blanks
> are word separators in a words clause.

Right on all counts.

> It really appears as if you either
> 
> (a) really think that "a<tab>b" ought to be a "word" in the
> words-clause sense -- which seems massively counter-intuitive -- or 

Ah, it only took you 10 postings to get my point. Good that we're now on the
same wavelength.

> If (a), I'd really like to see it defended.  It seems a massive flaw.

I believe I have posted more than enough on that topic, so I refer you to my
other messages.

  Eric