NetNews Usenet Archive 1992 #19/NN_1992_19.iso/spool/comp/lang/rexx/852

Text File | 1992-08-31 | 10.9 KB | 269 lines

Comments: Gated by [e-mail]
Path: sparky!uunet!paladin.american.edu!auvm!SERVER.UWINDSOR.CA!OPHOF
X-Mailer: ELM [version 2.3 PL11]
Message-ID: <[e-mail]>
Newsgroups: comp.lang.rexx
Date:         Mon, 31 Aug 1992 04:58:09 EDT
Sender:       REXX Programming discussion list <[e-mail]>
From:         Scott Ophof <[e-mail]>
Subject:      Re: Blanks, REXX, and portability...
Comments: To: [e-mail]
In-Reply-To:  <[e-mail]>; from "Dave Gomberg" at
              Aug 27, 92 10:32 pm
Lines: 254

On Thu, 27 Aug 1992 22:32:04 PDT Dave Gomberg said:
>...
>A standard mainly tells implementers what to implement, and to a lesser
>extent, users what kind of code to write.   If users don't know certain
                            ^^^^
A comment (partly relevant to the subject, but more to *REXX* and
programming in general):
REXX is for me the first *major* step in the direction of "being
able to program withOUT having to translate from a human language to
some form of non-READable 'language'".  I hope to see this trend
continue in the future!

Maybe someday someone will combine a REXX subroutine written using
Chinese idiograms where we use IF/THAN/ELSE with another using
Hebrew characters for the keywords and send the result to Eric who
sees the result in plain English (because his computer does an
automatic translation from Hebrew & Chinese), and incorporates it
all into a new function for REXX, which Anders builds into Regina
(of course reading it in Norwegian) and uploads to those little
green men at the Univ of Marsopolis...   Portability unimportant???


On Fri, 28 Aug 1992 18:22:23 GMT Eric Giguere said:
>Life is full of compromises.  So are standards.  I, for one, am disappointed
>in seeing an innocent question about what "blanks" are degenerate into an
>opinionated debate about the proper (or improper) design and mindsets of
>certain operating systems.

Bringing to the fore those design aspects and mindsets is necessary
to get an overview of all relevant aspects of the problem, so we can
work towards a solution which not only encompasses those aspects,
but also creates enough room in whatever solution is generated to
hopefully allow for many probably unexpected future problems.

>That's why I worry sometimes that CMS is perhaps having too much of an
>influence on the way REXX is being standardized.  I hope that's not the case.
>...
>to succeed.  But it would be sad if following a standard leads to failure.

I *hate* UN*X, manage to tolerate MS-DOS, and *love* CMS.
*REGARDLESS* of these feelings, I think REXX *can* grow to be a
"universally" useable and useful programming laguage, irrespective
of human language of the programmer and opsys.
Now you have my reason for bringing up the blank/REXX/portability
question in the first place.


On Fri, 28 Aug 1992 16:24:57 GMT Jon Schmidt said:
>...
>Here's my little program, written to explore the commercial UNIX
>REXX interpreter's definition and handling of blanks:
...[program deleted]...

Here's what it does on my PC:
       Test  Unix  PC
       --------------
        1    1     0
        2    0     0
        3    1     0
        4    0     0
        5    1     1
        6    1     1
        7    1     1
        8    2     2
        9    41    1

Somehow, I don't trust what the PC did...  Anyone care to append a
column for other systems?


On Fri, 28 Aug 1992 09:41:50 PDT Dave Gomberg said:
>There are really four questions:
>1. How do we seperate words?
>2. How do we save disk space?
>3. How do we save typist hassle?
>4. How do we make our printed output look nice?
>I claim we ought, on this list, to address only 1.  The others belong on
>the operating system, disk management, word processing, and desktop
>publishing lists.

REXX might well be(come) useful outside of point, so my question is
and remains:
What needs to be done to solve the whitespace/blank/space problem
within and between systems where it relates to REXX?


On Thu, 27 Aug 1992 15:09:14 GMT Jerry Campbell said:
>I think its a BIG mistake for an particular interpreter implementation or
>especially the ANSI committee to make any assumptions about the data a
>Rexx program may need to deal with.

First a disclaimer:  The following is *not* meant as a negative
reflection re the ANSI-REXX committee!
We can't help but make such assumptions; there are never enough
far-sighted people in a position with enough authority to "ram"
a decision through so that short-term thinkers don't get the chance
to screw up excellent long-term concepts.

>...                                             If you step back from
>this issue a bit and consider the possible uses of Rexx as an interprocess,
>intersystem scripting language I think its required that we not insist
>on "helping" the Rexx programmer port his programs with stuff like builtin
>*automatic* tab to space conversion and such.

>                    Now, expand the concept to other systems/hosts instead
>of local processes....

Yes, *please*!  :-)

I know someone who *insists* that a SPACE be used to separate the
two words of her last name (she's not a unique case)...
Any idea how many programs are Broken As Designed in this respect?
Here's where the "unbreakable space" comes into play.


On Sat, 29 Aug 1992 23:36:31 GMT Eric Thomas said:
>In article <[e-mail]>, [e-mail]
>(Anders Christensen) writes:
>>>                       Parse var data a b . ' A('c')' d
>> You use a Space character in the pattern to denote a whitespace.
>...                       If "search" functions interpret blanks as "any white
>space", how can I make a search on a binary key which happens to contain a $20?

No way you can then, with REXX the way it is...  :-(
I was rather shocked to discover that in certain envirs a literal is
not always a literal, ie. that parts of it *can* be interpreted.
That the "certain envir" is Unix is *TOTALLY* IRRELEVANT!!!
In REXX single & double quotes have the same syntactical meaning; to
quote a literal string, and *nothing* inside those quotes is allowed
to be interpreted.

Question:
How much breakage would occur if the double quotes retained that
meaning, but the single quotes were to allow interpretation to some
extent?  In other words:
      Parse var data a b . " A("
means "ASCII '20'X followed by 'A('".
But:
      Parse var data a b . ' A('
means "one whitespace followed by 'A('".


On Sat, 29 Aug 1992 17:02:32 GMT Eric Thomas said:
>Frankly, I am a bit surprised at the sheer amount of bytes of arguments,
>proposals and counter-proposals that this fairly simple "blanks and whitespace"
>problem has generated.

So am I, but then in the sense that there are *more* aspects to it
all than I had thought possible...  I'm glad they were brought up.

>                       Personally I can't see what is so complicated about it
>that requires proposals of more than 200 lines which touch about each and every
>function in the language, and what is so controversial about making it easier
>for unixers to process tabs et al the way they are used to - without breaking
>anything, of course.

I see a problem in that portability seems to rate less consideration
than I feel it should in this day and age.

>It is a fact that most non-EBCDIC systems use tabs in source code, and won't
>change their minds just because of REXX. So REXX interpreters running on ASCII
>systems should accept tabs as valid white space delimiters in source code.

What happens when John copies this source program to a system that
does NOT recognize tab as whitespace, and gives it to Jack to test,
without telling him it comes from an ASCII system?  Syntax error?
Would adding an error message stating use of illegal-whitespace-for-
that-system be a viable solution?

>A tab in a quoted string is a tab, not a blank, just like in C and other unix
>languages.                                      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 ^^^^^^^^^
Are you *100%* *SURE* of this?


>My turn to be flamed now :-)

Well..  I'll oblige you if you *really* want it.  But let's do it on
alt.flame with a discussion on how to induce the Internet and BITnet
worlds to work *together*...  (*EVIL* grin) ;-)


On Sat, 29 Aug 1992 17:06:23 GMT Eric Thomas said:
>I apologize for the previous post where I quoted everything and said nothing -
>I must have hit the wrong key. Here is what I meant to say :-)

Was it an "s" instead of "d"?...  >;->>>
Couldn't have been PF4 or PF6...  (hehehe)


>In article <[e-mail]>, [e-mail]
>(Anders Christensen) writes:
>> Eric Thomas <[e-mail]> wrote:
...
>No, and in my opinion this portability concern is what keeps you guys off track
>all the time. Portability between different systems is totally irrelevant, the
>only thing that matters is portability between different REXX interpreters on
>the same type of system.

I claim that with a nice set of functions translating the relevant
system commands to a standardised REXX I/O, portability *is* *very*
definitely relevant.  An external function package, of course.
And it's high time this matter is addressed, at least more seriously
than up to now...

>>    Since EBCDIC
>>    don't use Tabs, the Tabs in ASCII are translated into EBCDIC
>>    Spaces.
>By the way, ASCII tabs are translated to EBDIC "program tab". XEDIT does
>support tabs, but they are a software concept (controlled by a SET TABS editor
>command, rather than something you define on the setup screen of your
>terminal).

My apologies for not realizing sooner that we had a misunderstanding
here, Anders.  It was an automatic assumption on my part that you
knew all about EBCDIC tabs.  Sorry.


>> Regexps are very powerful, and definitively more powerful than the
>> ...
>...                                         Regular expressions are not
>precisely intuitive for this type of people :-)

Yes and yes.  Anyone interested in writing an RE(string,rexexp,...)
function for the not-casual user of REXX (thus effectively replacing
most of the built-in functions...)?


On Sat, 29 Aug 1992 07:09:37 PDT Dave Gomberg said:
>I hope you don't feel excessively flamed by this, and it is not my
>intent to dispute your right to your opinions, but I was trying to
>figure out WHY I reacted so negatively to your postings.  ...

You wanted to send this item privately, right?  :-)


A (rather selective) summary up to now:
 - The number of whitespace chars in char-sets *will* increase.
 - EXPAND(.,.) would solve a lot when REXX is concerned with data.
   It won't solve anything when source files are copied to a more
   restrictive system (unless those interpreters are updated)...
   How about it, IBM, Quercus (Commodore?)?
 - A literal is a literal is a literal.  Or is it?...  Can there
   be an extension/enhancement to allow a limited "maybe"?
 - Let REXX be "open-minded" on reading data, and predictable in
   output.
 - Not much interest in overall portability.  :-(


Sorry for the length.  ;-)   (but there's a lot of whitespace!)


Regards.
$$/