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

Text File | 1992-08-31 | 3.5 KB | 67 lines

Newsgroups: comp.lang.rexx
Path: sparky!uunet!mcsun!sunic!sejnet.sunet.se!eric
From: [e-mail] (Eric Thomas)
Subject: Re: Blanks, REXX, and portability...
Message-ID: <[e-mail]>
Lines: 54
Sender: [e-mail]
Reply-To: [e-mail]
Organization: SUNET, Stockholm, Sweden
References: <[e-mail]> <[e-mail]>
Date: Tue, 1 Sep 1992 00:21:57 GMT

In article <[e-mail]>, [e-mail] (Edward T Spire) writes:
> I would like REXX to be useful in the environment in which it is to be
> used.  Hence if it is to parse OS generated output that contains tabs
> where one would expect blanks, it is better to modify the REXX
> definition to be something useful for that environment rather than
> simply curse the darkness.

I think everyone agrees to that, the question is not whether REXX should make
it easy to parse system-generated output with tabs, but how, and, in
particular, how much of the language needs to be changed to provide a workable
solution to this problem.

Do not forget that the strength of REXX is that it is easy to learn by people
without the kind of background one needs to learn C or perl in a few
hours/days. Because they can learn REXX quickly, these users can easily improve
upon the interface the system is offering them and make better use of the
computer. If such a simple problem as correct handling of tabs et al requires
complex changes to about half of the aspects/functions of the language (see
Otto's proposal, which by the way would be a very good piece of work if it
really WAS necessary to change all that stuff), you are going to end up with a
factory like SNA, VMSES, you name it.

> The newer OS's do not have an external data queue,

Up to this point I fully agree with you.

> they are generally much more case
> sensitive than CMS, they support multi-programming, they will generally
> have GUI human interfaces, they will support a heavily networked
> environment, etc., etc.

Can we please avoid silly arguments about modern vs stone-age systems? Tabs are
far from being a recent invention, and I don't see anything in REXX which would
cause problems on a system like unix where case matters everywhere, unless you
are proposing to make statements and variables case-sensitive, which I
sincerely hope you are not. Multi programming is too difficult to specify in a
system-independent way to directly affect REXX, at least now. Not even C,
FORTRAN or PL/I have standard, system independent multi-programming primitives,
and they are "real languages" (things you write 500k-lines packages in). GUI
(which I will consider "human" the day I suffer from a total nervous breakdown
and start thinking of people as computers I supply input to and receive output
from) and networking issues (RPC et al) have all been addressed in "real"
languages with external libraries, without one change to the language itself.

Many years ago, a CMS programmer wrote a REXX interface to GDDM, IBM's graphics
system (this was well before IBM wrote the GDDM/REXX product). Even though the
languages GDDM had been designed for were FORTRAN, COBOL and PL/I, the
interface worked fine and one could happily call PSF from REXX (PSF is a
high-level menu-driven data display utility, the kind of thing managers can
understand). Frankly, I can't picture REXX coming with a built-in set of GUI
statements, a built-in set of RPC statements, and so on. If that's what you
guys are aiming for, I'm glad I've decided to drift away from REXX.

  Eric