From: anders@lise3.lise.unit.no (Anders Christensen)
Subject: Re: Blanks, REXX, and portability...
Organization: /home/flipper/anders/.organization
Date: 27 Aug 92 06:30:35

In article <9208270054.AA19196@SERVER.uwindsor.ca> Scott Ophof <ophof@SERVER.UWINDSOR.CA> writes:

> But I still don't see any need for more than one character being a
> blank, ie. the character that can always be used as separator of
> words.

Please reread the example at the end of my previous posting, where I
showed one example of why Unix need to interpret Tab as a blank.  I
don't think it is a matter of what is needed, it is rather a matter of
what already exists. All (true) ASCII machines use Tab and Space as
whitespace, although the use is most common on Unix machines.

> Thus the EBCDIC vs. ASCII issue becomes rather unimportant, [...]

I don't think so. ASCII uses multiple whitespace characters (Tab and
Space), while EBCDIC uses one. TRL does not explicitly address the
problem, but implicitly uses only one space character. This gives room
for implementors on ASCII machines to interpret "blank" as they need.
But if the standard includes a requirement that Rexx should *only*
have one space character, the running a true standard rexx interpreter
on some machine will become very difficult.

> Catering to envirs where characters are effectively abused because
> of antiquated needs to save space also seems to me to *not* be The
> Way To Go In The Future.

Sorry, but the future seems to go away from EBCDIC and One space, and
in direction of large ASCII based character set (32 bit) and Many
spaces. Note, this is _not_ done to save space (32 bit characters
don't exactly decrease the need for disk and memory). 

> Hitting the TAB-key (etc.) eases the work of the typist.  OK.
> But the data in the file should have the correct number of blanks.
> At the application level programmers should *not* need to concern
> themselves with the disposition of data in a (disk) file, as Dave
> Gomberg implies.

You want to make rexx data closer to human languages? Fine, then
remove the concept of a space character altogether. After all, the
space character is a computer kludge to deal with grouping of
characters. No human (Latin-based) languages use a space letter, they
use graphical letters separated by open space. The space it not a
letter, it is just emptyness.

> In going from one system to another, imho *no* translations like
> TAB-to-SPACEs should take place.  How can one parse on tabs when
> they have been converted to spaces in the ftp / copy / whatever
> process?

When taking from an ASCII to an EBCDIC system (or vice versa), you
_must_ translate the contents. The clue it that *you* don't parse on
Tab, the *computer* (i.e. the rexx interpreter) parses on Tab,
depending on the common customs of the host operating system. So
instead of forcing you, as a user to have to take care of the Tabs,
the computer (i.e. the Rexx interpreter) should handle it. The
interpreter can only do that if it knows what is whitespace and what
is not whitespace for your particular system.

You have not yet described a specific situation where the
interpretation of Space and Tab as whitespace on ASCII machines would
create problems on either ASCII or EBCDIC machines. I still assert
that this will not create any problems.

> Note that I said "standard REXX".
> Whether specific implementations decide to extend their definition
> for local purposes, I don't really care.  My concern is only for
> portability *regardless* of system.  And on all those I know (of),
> SPACE is the only character they all recognize as word delimiter.

That is a contradiction. If an implementation has 'local' extensions,
it is not standard anymore. If you really want a Rexx standard that
has any chances to become widespread, you should wish for a standard
that only defines what most people agree on, and leave the rest an
open question. If the standard is to strict, few people will use it.
The world is full of unused standards ...

As an implementor, my attitude is that I want to make the interpreter
compatible to the ANSI REXX, but if that standard is totally
impossible for those platforms I work on, then I have to make an
extension or non-standard behavior for the features that don't work.
And having added _one_ non-standard feature, the magic of ANSI REXX is
gone, and it is much easier (psychologically speaking) to add the next
extension ... etc

> So what is it that needs to be done to get all these envirs to end
> their (*OUR*!!) petty squables over minor differences and start
> working *together*?  :-)

I don't want to reform the rest of the world. I just want to write a
nice Rexx interpreter. In particular, I don't want to write a Rexx
interpreter that doesn't work, just because it is "standard".

> (Though not relevant to REXX, I do want to say that I'm getting sick
> & tired of opsys wars, Internet/BITnet/EARN bickering, the
> egotistical/greedy side of patenting/copyrighting, ad nauseum...)
> 
> Please, ANSI-REXX committee, keep up the good work to ensure a
> decent *overall* standard!

Yes, I agree!  On both points.

Someone posted earlier that CMS programmers often tend to regard the
format of data as very constant, e.g. that the interesting portion of
the output from command XXX starts in column 42, and is 8 characters
long. That is very different from the Unix approach, in which the
exact column where things start is often not constant, and where the
number of whitespace-separated words in the output is used to find the
right data. The difference can be seen from these two examples

    parse var foo 42 user +8
    parse var foo . . . user .

Rexx is powerful enough to handle both approaches. But this will only
work on Unix machines, if Unix Rexx interpreters are allowed to
interpret all Unix' whitespace characters as blanks.

No, I am not trying to start a opsys-war, and I think opsys-wars are
just a waste of time. But I do think it is important for Rexx to be
defined in such a way that it can be used under most operating system,
including Unix.

-anders
Newsgroups: comp.lang.rexx