X-Mailer: ELM [version 2.3 PL11]
Newsgroups: comp.lang.rexx
Date:         Wed, 26 Aug 1992 20:54:12 EDT
From:         Scott Ophof <ophof@SERVER.UWINDSOR.CA>
Subject:      Re: Blanks, REXX, and portability...
Comments: To: REXXLIST@uga.cc.uga.edu
              Christensen" at Aug 26, 92 8:56 am

On Wed, 26 Aug 1992 08:56:20 GMT Anders Christensen said:
>In article <9208260321.AA05688@SERVER.uwindsor.ca> ophof@SERVER.UWINDSOR.CA
>(Scott Ophof) writes:
>>...
>it is sometimes hard to predict it in advance, and it might differ
>from machine to machine, and from login-session to login-session.
                              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is a tough byte to swallow...

>>...
>TRL always uses the terms 'blank' and 'blanks', I believe?

Oops!  My apologies both to the list/group and Mike; I was still
thinking in terms of the 1st edition.  A quick run-through of the
2nd edition shows it to be more consistent (British understatement)
in using "blank"/ "blanks", as Anders remarks.

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.
*The* strong point of REXX is (imho) that it can so easily be used
in operations on human languages.  One qualification:  I restrict
myself to the character set of the Western world (and its national
variants) due to lack of knowledge re languages using pictograms
and such.

Thus the EBCDIC vs. ASCII issue becomes rather unimportant, as does
CMS vs. rest-of-world.
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.
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.

...
>I think you would hate even more to port a rexx program from one unix
>machine to another unix machine; and have the program fail due to one
>...

(Urgh)  :-(  No, I *won't* make a nasty remark about UN*X...   (grin)

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?

IMHO it's high time (computer) envirs put more effort into
standardizing *across the board*, putting behind them all the
antiquated stuff and petty local differences.
(I know, it's idealistic...)


>> My suggestion?
>> In the interest of increasing the chance of successful porting, to
>> request the ANSI-REXX committee to define that the *only* blank/
>> whitespace recognized in standard REXX is the SPACE character (ASCII
>> hex-20, EBCDIC hex-40).
>And there is indeed also a very good chance that this suggestion (if
>accepted) will make any rexx interpreter for Unix rather useless, or
>at best, just redline the astonishing factor (see end of posting for
>an example).

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.


>Section one of TRL states that Rexx "... involve the use of two
>character sets." One used for the rexx script (source code), and one
>used by the interpret under execution (data). If you want to define
>that a rexx script may only include certain characters as blanks under
>parsing of the source code (except in quotes and comments), that's
>fine. However, if you suggests that only certain characters should be
>recognized by the interpreter as blanks under execution (as data), then
>I fear Real Trouble.

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*?  :-)
(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!


>> Your comments?  :-)
>Please, by all means, standardize what a blank is, but *please*, don't
>standardize it in such a way, that it makes it impossible to use the a
>true standard Rexx interpreter on some platforms.
>My suggestion?
>In the interest of increasing the chance of successful porting of the
>Rexx standard itself from EBCDIC to ASCII based systems, to request
>that the ANSI-REXX committee explicitly allows the common whitespace
>characters of the host operating system to be interpreted as 'blank'
>characters, and that the definition of exactly what is blank, is
>implementation-dependent and system-dependent.

I think we effectively *agree* on the basics of the issue, Anders.
May I respectfully ask both the implementors and the users sections
of the ANSI-REXX committee, ex officio, for their views?


Regards.
$$/
Newsgroups: comp.lang.logo