HDTenEightyP/NetNews huggingface dataset:
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 8 Sep 92 17:20:26 GMT
	<MARTINC.92Sep7194817@grover.cs.unc.edu>
	<1992Sep8.155436.1@sejnet.sunet.se>
Organization: UNC Department of Computer Science
In-reply-to: eric@sejnet.sunet.se's message of 8 Sep 92 15:54:36 GMT

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

   > I think I should direct you to the note where I went over precisely what
   > I meant using regular expressions.

   Did you read your own note? I am getting the impression you are replying to
   the wrong message by mistake.

   > But I think your example is flawed:

   My examples are not flawed. I have written enough REXX code to know
   what a simple PARSE clause like the ones I quoted above does, if you
   don't believe me feel free to run them through your favourite
   interpreter. 

Then you should know enough about rexx code to answer my questions,
shouldn't you?

   As you said (and if I ever said the opposite I'd like
   you to show me where), PARSE does indeed strip both leading and
   trailing blanks from the first N-1 variables in a word parsing
   clause. That is precisely why you will lose column positioning if you
   use this form of parsing, as arbitrary amounts of blanks (or
   whitespace in your proposal) are silently eaten up. The only way you
   can remember what columns things were at is if you don't use this
   form of the PARSE statement, in which case it is totally immaterial
   whether or not it treats tabs as whitespace when parsing by word,
   since you won't be parsing by word, and again the conclusion is that
   having this behaviour does not help you in cases where you have:

   >    > repeated applications of parse, say with columnar fields.

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

(b) that you agree sensible behavior is that any whitespace character
NOT OTHERWISE INTERPRETED (like newline) ought to be a word separator.

If (a), I'd really like to see it defended.  It seems a massive flaw.
--
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: Blanks, REXX, and portability...
Date: 1 Sep 92 05:25:50 GMT
Organization: Missionaria Phonibalonica
X-NewsSoftware: Amiga Yarn 3.4, 1992/08/12 15:49:52

In <REXXLIST%92082801405886@UGA.CC.UGA.EDU>, Dave Gomberg <GOMBERG@UCSFVM.BITNET> wrote:
> If it is required that 20 characters be syonymized because the designers
> of a character set did not understand the distinction between a character
> set and a printer control languague, I for one don't want to buy a device
> that fools around with that character set.

Yeah, the designer of any character set that includes things like HT
(EBCDIC 05) or FF (0C) should be taken out and shot. And you'd
certainly never want to buy a device that used any such characteer
set.

You've consistently taken an antagonistic attitude about this problem,
apparently trying to smear things that aren't done the "true blue"
way, and usually incorrectly. The problem isn't that some OS does
things "wrong", or that some character set is "wrong." The problem is
that _people_ have become used to using more than one character to
mean space.

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.

Trying to place blame isn't going to solve any problems; it's just
going to antagonize people. What is needed is a solution that everyone
can accept. If it can be arrived at here, that's great - someone can
take it to the ANSI meeting. If it can't be arrived at there, then the
Rexx community as a whole will lose.

	<mike
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
X-Mts: smtp
Newsgroups: comp.lang.rexx
Date:         Sat, 5 Sep 1992 15:44:05 -0400
From:         cultural elite <dsr@LNS598.TN.CORNELL.EDU>
Subject:      Re: Blanks, REXX, and portability...
Comments: To: General REXX Language Discussion List
              <REXXLIST@ucf1vm.cc.ucf.edu>

Eric Thomas <eric@SEJNET.SUNET.SE> writes:
>In article <mwm.1p79@contessa.palo-alto.ca.us>, mwm@contessa.palo-alto.ca.us
 (Mike Meyer) writes:
>> A question for all of you using EBCDIC who don't think that arbitrary
>> whitespace should be allowed to seperate words: Why do you care?
>
>I have to use unix systems from time to time to get my job done. If some day
>they have a REXX interpreter, I would like to use it to make my job easier and
>for that it has to behave predictably. If I code POS('A B',string), I want it
>to locate A-blank-B, not A-tab-B. I have said that 200 times already, maybe you
>should read more carefully before you flame?

I agree, that would be ridiculous.  Not even Unix (with the possible exception
of a few broken utilities) behaves that way.  But is anyone actually advocating
that position?  Mike's question was specifically about word separators, which
I take to mean the behavior of parse when no explicitly quoted separators are
given, and the behavior of word() and words() and a few other intrinsics.
Accepting any whitespace as word separators would have no effect on your
example, or any other involving explicitly quoted blanks.  Where is the problem
with that?

>> A similar problem shows up in the ANSI C standard. It has this idiotic
>> restriction that external identifiers must be unique in the first six
>> characters, case insensitive. I don't know of _anybody_ who liked
>> this, but there was a very popular system which had a standard linker
>> with that antiquated restriction. Removing this brain-dead restriction
>> meant that you couldn't write an ANSI C compiler for that system,
>> which was considered a bad thing - so the restriction stayed in.
>
>In case I interpreted the snide remark correctly

Why were you looking for a snide remark?  It was an illustrative example.
I don't remember reading any requirement that illustrative examples be
(a) snide or (b) only about EBCDIC systems.

>It will make REXX hard to use for people who, for religious reasons, refuse to
>type PARSE EXPAND instead of PARSE wherever necessary. That is their problem,
>as far as I am concerned; I have no such religious diktat.

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.
--
Dan Riley                          Internet:   dsr@lns598.tn.cornell.edu
Wilson Lab, Cornell University     HEPNET/SPAN: lns598::dsr (44630::dsr)
	 "Maybe, leastways is the best way of all" -Caterwaul
From: bobcook@unixhub.SLAC.Stanford.EDU (Bob Cook)
Newsgroups: comp.lang.rexx
Subject: Re: NOVALUE (was: Blanks, REXX, and portability...)
Date: 12 Sep 92 01:18:34 GMT
Reply-To: bobcook@unixhub.SLAC.Stanford.EDU (Bob Cook)

Charles R. Martin writes
>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.

I think I gave the wrong impression.  I did not mean to say I thought it was  
incorrect; merely that I thought it was somewhat unfortunate.  I misled by  
including "At least, it doesn't on VM/CMS.", which was there just to say I only  
really know about that implementation.

I discussed this point (a LONG time ago) with Mike Cowlishaw.  He made it clear  
that the behavior was intentional, but (if I recall correctly) he chose it as  
the better of two choices, each of which had its pros and cons.  I think I  
agree with his choice.  But I ALSO miss having the reference to x in a.x  
treated as a NOVALUE condition.

Dave Gomberg writes
>There is no occurance of a variable named x in this program fragment.  There
>is a constant whose value is the single letter X in upper case, and there is
>a variable reference to a.x.  This is no more a reference to x then a.2 is
>a reference to the number 2.  To see this, notice that the number 2 (or any
>number) is to be taken in some base, while the notion of base is completely
>irrelevant in the reference to a.2.  There, 2 is just a one character string.

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.

--
Bob Cook                              bobcook@slac.stanford.edu
Stanford Linear Accelerator Center    NeXT mail okay
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Fri, 11 Sep 1992 10:10:05 MSZ
From:         ludger hinners-tobraegel <LHINNER@DGOGWDG1.BITNET>
Subject:      Re: REXX on UNIX?
              8 Sep 92 22:32:39 LCL from <anders@LISE1.LISE.UNIT.NO>

On Tue, 8 Sep 92 22:32:39 LCL Anders Christensen said:
>
>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).
>

Are there 'free' implementations of REXX for DOS, too?
Perhaps for DOS 5.0 or DRDOS 6.0 ?

We use an older version of an implementation of REXX for DOS.
(personal rexx version 1.60; Mansfield)
This version is said to work fine with DOS 3.3.
But with DOS 5.0 or DRDOS 6.0 we cannot use the programstack
correctly.


Ludger Hinners
Institute of agriculture economics
University of Goettingen
Germany
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Tue, 15 Sep 1992 12:49:48 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Expressions in compound variables (was Re: NOVALUE)
              15 Sep 1992 15:33:20 EDT from <ophof@SERVER.UWINDSOR.CA>

Wait, Scott, this isn't FORTRAN subscripting.  What if I want a
reference to A3.  Can I code: I=3;  X=A(I)  ?   Why not?  This is
where the REXX committee fell apart in its determination.  We
understand the desire for inplace expressions, but felt in the
end that VALUE was a small enough price.  There you would have:
I=3; X=VALUE('A'I).  And there is now a pseudovariable as well.
How is that so terrible?      Dave
From: zjlc12@hou.amoco.com (Jerry Campbell)
Newsgroups: comp.lang.rexx
Subject: Re:      Re: Blanks, REXX, and portability..
Date: 14 Sep 92 13:58:40 GMT
Reply-To: zjlc12@hou.amoco.com
Organization: Amoco

In article 1@sejnet.sunet.se, eric@sejnet.sunet.se (Eric Thomas) writes:
>In article <1992Sep11.190834.16887@hou.amoco.com>, zjlc12@hou.amoco.com (Jerry Campbell) writes:
>>     3 - each word oriented, builtin function will have an extra parameter that
>>         can be used to override the implementation default.  
>
>Many of these functions already have a bunch of optional parameters. We're
>talking about ending up with things like FUNCTION(A,B,,,'20090D0A'x) with each
>function having a different amount of commas, not to mention the hassle of
>typing the list of delimiters every time.
>

I agree that more parameters are a pain.  But I think that this capability would
be very useful for lots of things, not just handling what Uni* call whitespace
and VM don't.  This would be an optional parameter, you'd get the default 
otherwise, which probably would be ok as long as you agreed with the implementor's
idea of what are good delimiters.  And you could change the default characters
with a ONE TIME call to,  Options blah delimiters,  OR with a bif, as was 
suggested by Dave Gomberg,  setdelimit(...).

I think the whole problem reduces to,  either define some kind of program
control for this,  or hang it on the implementor's shoulders and hope you like
what he/she decides (there's no way you can standardize a set of whitespace 
characters). 

>>     4 - logical comparisons will use the implementation default delimiters to
>>         fudge the ends of strings.  Unless the strict comparator operators are 
>>         used.  
>
>Which gives you an incomplete/inconsistent tools - for some things you can
>define your delimiters, for others you can. Not very convenient I'm afraid.
>
>  Eric

You CAN define them for everything (did I miss a spot?).  You can set "global"
delimiters.  Or override them in builtins.  Not very elegant, I agree.  But
I think it would be a good thing to think of delimiters as just another
string handling concern, along the level of the pad char that some functions use.
I don't think we should make this harder than it is. The thing that's futsy, fudgy, icky, is the what constitutes a legal leading/trailing don't care char.


---
Jerry Campbell   reply to: zjlc12@hou.amoco.com 
Amoco Corp. ISD  SSS/Graphics
Houston, Tx.     713/556-7036
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Tue, 8 Sep 1992 21:45:13 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              8 Sep 1992 13:50:26 -0400 from <dsr@LNS598.TN.CORNELL.EDU>

Dan, even without normalization (such as is called for by FORTRAN and
the floating point ANSI standards) you will still have problems with:

   X=expr
   PUSH X
   whatever code on X
   PULL X
   whatever code on X

and the two versions of the whatever code don't do the same thing.  Too
confusing for my little brain.   Dave
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sun, 6 Sep 1992 22:28:31 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              7 Sep 1992 02:29:25 GMT from <martinc@GROVER.CS.UNC.EDU>

OK, Charlie.  I get your point.  But the Unix folks claim they need to
match the tab.  Some of us say the solution is to replace the tab by
n blanks where n is some number they decide is right in context.  But
of course, 'a b' does not occur in 'a  b'.  So I suppose how many blanks
they decide to expand the tab to is critical in the case of pos.  But for
WORD/WORDS and PARSE with a variable list, it may not matter.  I guess we
need a better feeling for what Unix folks think they need.  Being a PC
folk myself, I don't much care, but we should try to help if we can.
From: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 9 Sep 92 13:57:49 GMT
Organization: UNC Department of Computer Science
In-reply-to: GOMBERG@UCSFVM.BITNET's message of 8 Sep 92 17:21:06 GMT

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

   On Tue, 8 Sep 1992 12:32:48 -0400 cultural elite said:
   >Dave Gomberg <GOMBERG@UCSFVM.BITNET> writes:
   >>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
   >
   >Ok, call me blind, I but I can't see this hole I seem to be in.  You'll
   >have to explain how you get c=a||b; pos(a,c)=0 out of any sensible
   >proposal.

   If the synonymy of tabs to a particular number of blanks were accepted, and
   if assignment did normalization (as it often does, both in standards and in
   practice) then c might well have a tab when a ended and b began with strings
   of blanks.   Dave

I think part of the point is that there can't be a standard equation of
TAB to some number of blanks; that's what crosses up the hoped-for
identities.  But that question seems orthogonal to whether blanks and
tabs ought both be whitespace.
--
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: martinc@grover.cs.unc.edu (Charles R. Martin)
Newsgroups: comp.lang.rexx
Subject: Re: Blanks, REXX, and portability...
Date: 5 Sep 92 17:50:20 GMT
	<1992Sep5.132440.1@sejnet.sunet.se>
Organization: UNC Department of Computer Science
In-reply-to: eric@sejnet.sunet.se's message of 5 Sep 92 13:24:40 GMT

I hate to throw a hint of reason into an otherwise promising flame war,
but I'm not at all clear on what the problem is.

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.

2. On the other hand, I don't quite see the problem in say parsing a
   line with 'parse <source> foo bar' as separating the foo and bar
   substrings with arbitrary whitespace.  That behavior would both fit
   standard conventions in widely-used interactive environments AND
   seems consistent with other rexx conventinos.  (After all, even a new
   rexx programmer like me has noticed that parse doesn't care if it is 
   only one blank space or several between the substrings.  Nor would
   one want it to be different.)

3. The use of tabs vs spaces in other systems is very generally such
   that columnar counts count a TAB char as a SINGLE character, i.e. 
   "a\tb" is a three character string in C.  It more or less must be
   that way since the 'padded' interpretation of a tab is dependent on
   the context -- the tab in "a\tb" isn't the same apparent width as the
   tab in "ab\tc", and the problem only gets worse in a proportional
   font.

So what's the problem with

	parse arg foo bar

parsing with the blank being an assumed regular expression of [ \t]+,
but with columnar counts remaining as they always have been?  You could
always parse with foo' 'bar if you want to insist on blanks by ghod.
--
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: beman@terapin.com (Bemis Jarvis)
Newsgroups: comp.lang.rexx
Subject: COMPILER FOR AREXX? HAS ANYBODY TRIED IT??
Date: 5 Sep 92 21:21:53 PST
Organization: BBS

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.
Comments: Gated by NETNEWS@AUVM.AMERICAN.EDU
Newsgroups: comp.lang.rexx
Date:         Sat, 12 Sep 1992 07:47:13 PDT
From:         Dave Gomberg <GOMBERG@UCSFVM.BITNET>
Subject:      Re: Blanks, REXX, and portability...
              11 Sep 1992 19:08:34 GMT from <zjlc12@HOU.AMOCO.COM>

Jerry, rather than something global, what about a bif:

 x=setdelimit(y)

sets x to the old string of delimiters (now only one blank) and makes
y, which must contain only one occurance of each distinct character in
y, the new set of delimiter characters.  Of course, it would probably
destroy performance and drive implementers nuts, but since when has
that stopped us?!!?   Dave
From: GOMBERG@UCSFVM.BITNET (Dave Gomberg)
Newsgroups: comp.lang.rexx
Subject: Re: Relaxing of argument-passing restriction?
Date: 15 Sep 92 06:01:15 GMT
Comments: Gated by NETNEWS@AUVM.AMERICAN.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:
>This restriction has always been a problem in building really good
>stuff in REXX.
>Who can come up with really valid reasons for having this max of 1
>apply to programs called as commands?  And/or other reasons PRO
>relaxation of the restriction?

Certainly this restriction didn't hurt CMS folks, who love REXX even
the way it is.  I guess I don't understand the problem?   Dave
From: jasienrt@outb.wimsey.bc.ca (Jason Sienart)
Newsgroups: comp.lang.rexx
Subject: Re: Requesters.. How do i get rid of 'em..
Date: 10 Sep 92 15:54:32 PDT
Organization: Wizard Online

How would i put that in a script.. order???

--- Via UCI v1.02 (C-Net Amiga)

#----------------------------------------------------------------------------#
|                                                                            |
|       J A S O N   S I E N A E R T     -    jasienrt@outb.wimsey.bc.ca.     |
|                                                                            |
#----------------------------------------------------------------------------#
From: beard@toadflax.cs.ucdavis.edu (Patrick C. Beard)
Newsgroups: comp.lang.logo
Subject: Re: PD Mac LOGO?
Date: 12 Sep 92 04:00:00 GMT
Organization: Department of Computer Science, University of California, Davis

In article <1992Sep11.045706.10414@cam.compserv.utas.edu.au> dbenn@leven.appcomp.utas.edu.au (David Benn) writes:
>Are there PD implementations of Logo for the Mac? Which ftp site(s)?

I picked up a test release of UCB logo from an ftp site at an  ftp site
at Berkeley. Unfortunately, I don't know the ftp site by name, and it's not
in the code I have. Nuts. Perhaps the people working on UCB Logo would
care to repost its location?

Good luck.

-- Patrick Beard
From: bh@anarres.CS.Berkeley.EDU (Brian Harvey)
Newsgroups: comp.lang.logo
Subject: Re: difference between LOGO Writer and LOGO
Date: 4 Sep 1992 21:33:51 GMT
Organization: University of California at Berkeley
NNTP-Posting-Host: anarres.cs.berkeley.edu


LogoWriter is a dialect of Logo sold by Logo Computer Systems, Inc.
It has a small word processor built in, so that text can easily be
combined with turtle-graphics pictures.

The LogoWriter user interface is pretty different from most other
dialects of Logo.  Instead of workspace files, programs are
organized as "pages" that include both procedure definitions and
a graphics window.

The actual programming language, though, is pretty similar -- although
LCSI did leave out some of the more advanced programming capabilities
for no very good reason.  So you can't use CATCH and THROW, or LOCAL,
or DEFINE and TEXT (although these last two can be simulated).

There's not much more to say unless you really want the gory details.
Most Logo programs that are intended for young (elementary school) kids
will probably look the same in LogoWriter as in other dialects.