HDTenEightyP/NetNews huggingface dataset:
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 7 Sep 92 14:42:22 GMT
Organization: UNC Department of Computer Science
In-reply-to: GOMBERG@UCSFVM.BITNET's message of 7 Sep 92 05:28:31 GMT

Is the point that they need to match the tab in POS?  Or was that a base
canard introduced in the flaming?  I myself would be *real* surprised at
a substring position operation that matched both blank and tab in this
context. 

But I think the point is that in the parse operation, with something
like

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 can't think of much of a
context in which this wouldn't be a (the?) sensible interpretation, and
you can easily write a parse specification that will get blanks
specifically if that's what you want.

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.)
--
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: mwm@contessa.palo-alto.ca.us (Mike Meyer)
Newsgroups: comp.lang.rexx
Subject: Re: Eric's question
Date: 5 Sep 92 04:19:21 GMT
Organization: Missionaria Phonibalonica
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52

In <1992Aug29.233631.1@sejnet.sunet.se>, eric@sejnet.sunet.se (Eric Thomas) wrote:
> If my space matches a tab, how do I do when I *have* to match a space, and only
> a space? I suppose I can't. I suppose we are back to the typical unix situation
> where strings that contain arbitrary characters cannot be manipulated with the
> standard functions provided by the language, and where you have to implement
> your own set of routines for such purposes.

If your language implementation is so broken that it can't manipulate
the strings that occur in your environment, then you should obviously
use another language.

In <ANDERS.92Aug29194248@lise3.lise.unit.no>, anders@lise3.lise.unit.no (Anders Christensen) wrote:
> If you move to Unix machine, then you want to write the rexx script
> from scratch (that's how I understand your 'No'). Then you should use a
> dataformat more suitable for the Unix environment. 

Of course, you may not have that option, in which case the solution is
to choose a better language. That may be a better solution in even if
you can change the data format.

And this is the point. If the language is defined in such a way that
it can't deal with strings in some environment, then it won't be used
in that environment. In this case, "that environment" includes the
majority of the platforms in the world. Hopefully, things can be left
so that the minority of platforms that Rexx originated on can go about
their business without noticing things.

Once again, C has a similar situation. Several standard practices on
DEC Unix boxes are defined to have "undefined behavior". That's
because those behaviors can't reliable be implemented on other popular
platforms. All the standard did was declare the world to be as it is.
This didn't make people writing code on those boxes change their
behavior (even though some of them thought it did), all it did was
make it obvious that they were writing non-portable code. Which they
would have known if they'd ever tried to port their code.

There should be an analagous solution in the Rexx world; hopefully one
that won't be so badly misunderstood.

	<mike
From: SEB1525@MVS.draper.com (Steve Bacher)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 7 Sep 92 18:18:00 GMT
Organization: Draper Laboratory

In article <mwm.1q4t@contessa.palo-alto.ca.us>,
mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:

>Those same people, when faced with an EBCDIC system, will try and use
>the "TAB" key exactly like they have before. They'll get upset and
>complain about the system if it doesn't do what they expect. They will
>complain that the system is doing things wrong. From their point of
>view, they'll be right.

Yeah, especially because on a 3270 (real or simulated), the TAB key
isn't a character at all, but a terminal control operation!  So when
they complain that the system isn't behaving right, this isn't
something that changing the definition of REXX can fix.

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sun, 6 Sep 1992 22:32:37 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              7 Sep 1992 02:42:09 GMT from <martinc@GROVER.CS.UNC.EDU>

Well, the Unix folks have rather dug themselves a hole on that one,
haven't they, Charlie.  It's not just a question of parse, what about
substr, or left/right.  They will have the same problem.  I guess we
could say that just because c=a||b doesn't mean expand(c)=expand(a)||
expand(b).  But we knew that already.  And your parse example is just
this problem in another guise.  In fact, the Unix folks have a worse
problem.  You can have c=a||b, but pos(a,c)=0!  Wow!  I don't think
I want that in MY os.  But there is no accounting for taste!   I would
really like Anders (I assume the first letter is in fact capitalized)
and other Unix types to say if they can stand it that:

    c=a||b;  say pos(a,c)

would say 0?  It is not what I mean by REXX.  Sorry this rambles so.  Dave
From: eric@sejnet.sunet.se (Eric Thomas)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 5 Sep 92 01:00:55 GMT
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden

In article <1992Sep4.154621.2334@wrkgrp.COM>, ets@wrkgrp.COM (Edward T Spire) writes:
> eric@sejnet.sunet.se (Eric Thomas) writes:
> : No question here. But wouldn't the unix version of XEDIT exhibit the same kind
> : of behaviour as the CMS version? Or does it, too, use tabs in the data returned
> : by (say) EXTRACT?
> 
> Not normally, but if you were editing a makefile that had tabs as part
> of the data lines and you extracted a data line...

*sigh* Very intelligent remark I must say. Extracting raw data from the file
can obviously return any possible value from 00 to FF, since the file can
contain bytes of any value. When editing a makefile, you furthermore want to
make very sure that tabs are NOT automatically treated as blanks, since they
have a totally different syntactical meaning.

> I am not joking, nor are the other folks who choose this route.
> Hardware performance bottlenecks are becoming less important as
> price/performance ratios change.

If performance is the only problem you have noted, you have missed the whole
picture. One example among many: how can I write a routine that will sort a
stem the caller passes as argument? Given that I can't, how do I share the
routine in question between several REXX source files? Choice 1, I write a huge
REXX file with all 30,000 lines of code in it (a technique commonly called
"modular programming" which improves robustness and programming efficiency).
Choice 2, I use the editor to copy the routine wherever I use it, and have 200
places to fix if it turns out to be buggy (of course the stem I need to sort
will have a different name every time). Ah well, there is no deafer man than
him who does not wish to hear.

  Eric
Newsgroups: comp.lang.rexx
From: SEB1525@MVS.draper.com (Steve Bacher)
Subject: NOVALUE (was: Blanks, REXX, and portability...)
Organization: Draper Laboratory
Date: Fri, 11 Sep 1992 00:44:00 GMT

In article <mwm.1udh@contessa.palo-alto.ca.us>,
mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:

>> 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.
>
>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
>programing language that has the same design flaw.

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.

>That's also the only thing on that list that Rexx does differently
>from my favorite language.

Hmmm - what could that be?  PL/1?  No, COBOL!   :-)

--
Steve Bacher (Batchman)                 Draper Laboratory
Internet: seb@draper.com                Cambridge, MA, USA
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sat, 5 Sep 1992 08:24:41 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Question about stems and storage...
              2 Sep 1992 17:51:47 +02 from <stud02@CC4.KULEUVEN.AC.BE>

Freeing storage (several Kb per stem)  Chris, it's only virtual storage.
Saving "several Kb" of virtual storage, unless there are hundreds of
them to save, is probably not even worth a second thought.  Unless you
are running up against a 16M boundary (which currently constrains REXX)
I suggest you not worry about it.

But your basic point is valid, suppose it were several Mb per socket.
Then the way to do it would be to make each socket be its own stem, and
use VALUE a lot.  That way, when you dropped a socket, you WOULD drop
the whole stem.  Another solution would be to beat on your vendor to
support a garbage collect routine that could be called when you were
dropping something big.   Good luck.   Dave
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Tue, 15 Sep 1992 10:41:35 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: NOVALUE (was: Blanks, REXX, and portability...)
              15 Sep 1992 02:01:30 GMT from <bobcook@UNIXHUB.SLAC.STANFORD.EDU>

On Tue, 15 Sep 1992 02:01:30 GMT Bob Cook said:
>Dave Gomberg writes
>>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.
>
>Would your credulity shrink back to normal if the code started with
>"a. = whatever"?
>
>--
>Bob Cook                              bobcook@slac.stanford.edu
>Stanford Linear Accelerator Center    NeXT mail okay

You bet.  I rarely use assignment to a stem, so I don't get hit by that
often.  I am not sure why I rarely use it, but it's so.  Dave
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sat, 5 Sep 1992 12:48:38 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              5 Sep 1992 17:50:20 GMT from <martinc@GROVER.CS.UNC.EDU>

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?
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: Sat, 5 Sep 1992 13:47:20 GMT

In article <mwm.1pdx@contessa.palo-alto.ca.us>, mwm@contessa.palo-alto.ca.us (Mike Meyer) writes:
> In <1992Aug27.175521.1@sejnet.sunet.se>, eric@sejnet.sunet.se (Eric Thomas) wrote:
>> Ok, time for the usual stupid question. Say I have a program that does:
>> 
>>                   Parse var line ':'tagname'.'value' :'line
>> 
>> Say I run that program on an ASCII system which recognize the 20-odd types of
>> blanks Otto showed in his posting. Where does my 'value' variable end, when the
>> interpreter encounters a SPACE followed by colon (ancient, despicable, evil
>> EBCDIC-type behaviour, surely that must not be the case), or also when it
>> encounters TAB followed by colon (nice, modern ASCII-type behaviour which
>> happens to break the program because that is not what the programmer wanted
>> and thought the interpreter would do).
> 
> What you want it to be is whatever whoever generated the input thought
> it would be.

Ah yes, the interpreter uses its divinatory powers to read the mind of whoever
generated the input? Seeing a literal of ' :', it thinks "Aww, this must be one
of these NAMES file IBM thingies, let's stop on a blank only". Seeing ': ', it
thinks "Ah, this is clearly someone parsing a RFC822 header, let's stop on any
white space".

> I.e. - I have to accept both space and tab as space, because the
> standards document I'm using _says_ I do.

Really? Damn. I have all this mail software in REXX on my VM machine where the
interpreter only stops on blanks, how can I possibly have made it respect the
RFC? It must have cost me thousands of lines of code. Let me check it. Oh, it
looks like all it took was a function call on ONE line out of several thousand,
the one in the loop that reads the incoming header and calls the parser! But to
think I had to key in an extra 30 characters when THE SYSTEM should have known
what I meant to do and done it for me :((((((( I will petition the ANSI REXX
committee to change the language so I never have to do that again!!!!!!

Anyway, I understand the issue much better now: we're back to the usual
religious arguments. People like Mike will never accept a solution which they
perceive to be un-unixish. Well as Mike pointed out, I don't really give a damn
since I'm moving away from REXX, but I find this both funny and saddening. 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. REXX has its own personality, and it can never become unixish no
matter how hard you try. So I find it strange that people who want to unixify
REXX even bother, when there are a lot of other unix scripting languages to
choose from. On the other hand, I am not really surprised - the spirit of the
crusades will live forever, I suppose this is human nature.

  Eric
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sat, 5 Sep 1992 12:56:47 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              5 Sep 1992 15:44:05 -0400 from <dsr@LNS598.TN.CORNELL.EDU>

On Sat, 5 Sep 1992 15:44:05 -0400 cultural elite said:
>PARSE EXPAND is not such a simple solution, as in some situations it will
>require tracking both the expanded and unexpanded copies of input lines.

No it wouldn't.  Why would it?   PARSE EXPAND VALUE psrc WITH template means
the same as $temp=expand(psrc); PARSE VAR $temp template  , right?
From: GILMART@LSTC2VM.stortek.com (Paul Gilmartin)
Newsgroups: comp.lang.rexx
Subject: Re: NOVALUE (was: Blanks, REXX, and portability...)
Date: 12 Sep 92 06:22:02 GMT
Organization: StorageTek SW Engineering

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
  ^^^^^^^^ (I'd say "very" -- gil)
>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
 
But it would be a real pain if this were reported as an error unless there
were some way to use explicit constants -- better by far, general expressions
-- as compound variable indices.  Namely:
 
   say a.'X'   /* so I don't have to assign 'X' to dummy */
               /* and even:  */
   say a.(substr('UVWXYZ',4,1))   /* Why not, haven't you wanted it? */
 
Is anyone proposing this extremely desirable extension?
 
gil
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Mon, 14 Sep 1992 15:04:42 EST
From:         KMITRA@CCVM.WCUPA.EDU
Subject:      Need help
Comments: To: rexxlist%ohstvma.bitnet@pucc.princeton.edu

Hi,
   I am wondering if someone knows how to hide text display while an user
is entering PASSWORD. Thanx in advance
                                         KMitra
From: eric@sejnet.sunet.se (Eric Thomas)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 7 Sep 92 19:00:18 GMT
Reply-To: ERIC@SEARN.SUNET.SE
Organization: SUNET, Stockholm, Sweden

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

  Eric
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 7 Sep 92 02:42:09 GMT
Organization: UNC Department of Computer Science
In-reply-to: GOMBERG@UCSFVM.BITNET's message of 7 Sep 92 00:56:46 GMT

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

   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

The problem would come with multiple applications.  Now, be kind on
technical syntax here (um, is that spelled syntaxx for rexx?) because
it's a new language for me and I don't have a manual at hand.  But
consider 

parse expand value 'ab\tcd' with fld_a 01 02 rest_a

where you should interpret the "fld_a 01 02" as the appropriate field
description for a two column field taking the first two characters.  I
think we're agreed that the result should be

fld_a="ab"
rest_a="      cd"  (modulo me counting blanks right on that line.)

so that if we did 

parse expand value 'ab\tcd' with line_a

then we'd expect line_a to equal fld_a||rest_a

But what if we instead 

parse value 'ab\tcd' with fld_b 01 02 rest_b

and follow that with

parse expand value rest_b with line_b

so that the expansion happens in the second parse and not the first?
How many blanks must be added to replace the TAB character?  In the
first case, we added 6 characters -- but to preserve the meaning of TAB
as 'tab to column 9' we must add *8* characters in the second; suddenly
we find that line_b DOES NOT equal fld_b||rest_b, which is aberrant.
--
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-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Mon, 14 Sep 1992 16:23:04 EDT
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      ARG() behaviour
Comments: To: REXX Discussion list <REXXLIST@uga.cc.uga.edu>

Sub:  ARG() behaviour

The ARG() function behaves differently in different implementations
and levels.
The following returns either 4, 5, or 6, depending on the opsys.
Note that there are 5 commas in the call to FUNCTION()...

   /* Behaviour of ARG() */
   Trace OFF
     Say Function('The number', 'of',, 'argstrings',,)
     Exit
   Function:  Procedure
     Return arg

According to "The REXX Language" (2nd edition), "4" should be the
correct answer.  Has this changed since TRL-1?
And what is the correct answer?
How strict is "explicitly specified as an argument string when the
routine was invoked" (TRL-2, page 83)?

Your views, please.


Regards.
$$/
From: GOMBERG@UCSFVM.BITNET (Dave Gomberg)
Newsgroups: comp.lang.rexx
Subject: Re: NOVALUE (was: Blanks, REXX, and portability...)
Date: 12 Sep 92 14:58:09 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
              12 Sep 1992 06:22:02 GMT from <GILMART@LSTC2VM.STORTEK.COM>

On Sat, 12 Sep 1992 06:22:02 GMT Paul Gilmartin said:
>But it would be a real pain if this were reported as an error unless there
>were some way to use explicit constants -- better by far, general expressions
>-- as compound variable indices.  Namely:
>
>   say a.'X'   /* so I don't have to assign 'X' to dummy */
>               /* and even:  */
>   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.  The new VALUE pseudo-
variable solves the problem pretty well (it never was much of a problem
on the right-hand side of an assignment).   Dave