Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!ucla-cs!zen!ucbvax!hplabs!well!ewhac
From: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Newsgroups: comp.sys.amiga
Subject: Re: AREXX and ICP
Message-ID: <3939@well.UUCP>
Date: Sat, 12-Sep-87 17:34:12 EDT
Article-I.D.: well.3939
Posted: Sat Sep 12 17:34:12 1987
Date-Received: Sun, 13-Sep-87 10:45:12 EDT
References: <267@mitsumi.UUCP>
Reply-To: ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab)
Organization: UmeCorp.  Pay us some money and we'll invent something for you.
Lines: 90
Summary: Use the filespace.

** REPLACE THIS LINE WITH A TEN DOLLAR BILL AND RETURN IT TO THE SENDER **

	I attended the BADGE meeting where REXX was discussed.  As I
understood it, REXX can be thought of as nothing more that an intelligent
pipe device.  You feed it data, it does things to it, it spits the new data
out.  I get the feeling it's more than this, but I can't think what.

	Assuming it *is* just a smart pipe, then I think it should be
written as a device in the AmigaDOS filespace (like, maybe, REXX:).

	The objective of REXX is data exchange between programs, with REXX
converting the data format if necessary (at least, that's how I understand
it).  We already have a form of this.  It's RAM:.

	Now before you accuse me of being silly, think about it for a
moment.  All *CURRENTLY EXISTING* Amiga programs that read, manipulate, and
store data have one thing in common:  They all know how to talk to the
AmigaDOS filesystem.

	Currently, people who want to convert data from one format to
another save the data to RAM:, run a utility to convert it, and then load
the converted data into another program.

	So.  My idea was to make REXX an object in the AmigaDOS filespace,
with the following implementation details.  There would be REXX proper (the
actual language interpreter), and a REXX controller (language editor, which
feeds programs to REXX proper.  It'd have windows, gadgets, menus, etc.).
REXX proper would exist in the AmigaDOS filespace, and would receive control
messages from the REXX controller via standard Exec messages.  The message
packets would be documented, so that some other developer could create his
own controller, if need be.

	Now, here comes the good part.  REXX programs (under my scenario)
would have names associated with them.  To access these REXX programs from
"ordinary" programs, you would specify them as "filenames" existing on the
REXX: device.  Writing to this file (it's a file as far as outside programs
are concerned) would supply data to the input stream of the REXX program of
the same name.  Reading this file would provide the output the REXX program
generated.

	The type of scenario I'd like to see happen goes like this:  You
start up REXX proper, feeding a REXX program (we'll call it 'convert').
Next, you start up your favorite editor, and go to work on a program.
Eventually, you find the need for some graphic imagery in the form of source
code.  Using Super-Dooper multitasking, you start up DPaint, and create an
image.  You then grab it as a brush.  Then, you tell DPaint to save this
brush to a file called "REXX:convert".  DPaint happily does this, since it
can read and write files with no trouble.  REXX proper grabs this data, and
feeds it to the input of the 'convert' program.  You then go back to your
favorite editor, and ask it to insert into the current edit buffer the
contents of the file "REXX:convert".  The editor gleefully reads the stream.
Shortly thereafter, all this BOB source code magically appears on your
screen, converted directly from the brush ILBM by REXX.

	Have you noticed something about this?  I didn't have to rewrite
DPaint or my favorite editor to take advantage of this.  As it was presented
at the BADGE meeting, any program that wanted to take advantage of REXX
would have to have special code to do it.  You'd need to create special
message ports and code to deal with it all.  I think this is unnecessarily
shortsighted.  I believe my scenario has greater practical functionality, as
it requires *zero* modification of existing programs.

	The only thing that would be required of outside programs is that
they be able to read and write arbitrary chunks of data to a file.  I don't
know if existing spreadsheets can save arbitrary ranges of rows and columns;
I know that many editors/word procesors don't allow you to save arbitrary
chunks of text.

	Can anyone see any holes in my thinking?

In article <267@mitsumi.UUCP> jimm@mitsumi.UUCP (James Mackraz) writes:
>The worst thing I heard was that the execution environment of programs
>loaded by REXX would be yet different from both the CLI and the Workbench
>environments.  Just what the world needs, another condition in application
>start-up code.  The WB environment was described as inadequate, without
>justification.  (Slurs against the CLI environment need no further
>justification.)
>
	I agree with this assertion.  We don't need YA Startup Environment.
I've never written a "correct" Workbenchable program, because I perceive it
to be too much trouble.  If a third environment pops up, I'll probably crawl
into a hole somewhere.... :-)

	As always, this is just me talking.

_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_
Leo L. Schwab -- The Guy in The Cape	ihnp4!ptsfa -\
 \_ -_	 Bike shrunk by popular demand,	      dual ---> !{well,unicom}!ewhac
O----^o	 But it's still the only way to fly.  hplabs / (pronounced "AE-wack")
"Work FOR?  I don't work FOR anybody!  I'm just having fun."  -- The Doctor