randy@bcsaic.UUCP (Randy Groves) (01/01/70)
Once again the question: What is the status of REXX?? Is it a product? Is it PD software? How and when will it be available? I've not seen anybody who seems to know about the existence of this software that has mentioned even a hint of this info. Thanks much. -- -randy groves - Boeing Advanced Technology Center UUCP: ..!uw-beaver!uw-june!bcsaic!randy USNail: Boeing Computer Services CSNET: randy@boeing.com PO Box 24346 M/S 7L-68 VOICE: (206)865-3424 Seattle, WA 98124
jimm@mitsumi.UUCP (Jim Mackraz) (09/11/87)
Now that our newsfeed is working, I am reposting these comments on
Inter Process Communication and AREXX on the Amiga. They are
a little old.
--------------------------------------------------------------
Since I haven't sounded too supportive of WHawes AREXX project,
I should clarify.
For background to those even less knowledgable than I, AREXX is
a powerful interpreted (i think) language which reminds many people
in purpose of the C-shell script language, but is reported to be
much more powerful. The language program has the capability to
send messages to applications, which if matched with applications
which understand the messages, can give flexible "macro" capability.
To understand the context and reason for my remarks, it is probably
necessary to have been at the relevant BADGE meeting. Part of my
villian role comes from my missing a portion of that meeting.
My comments, nevertheless, follow.
I like the language part of REXX. I think it does/will make a
fine product. I have problems with two things: 1) the unnecessary
and (my view) unhealthy assumption that interprocess messages
are somehow tied in to the rexx effort, and 2) the specifics proposed
for the protocol of these messages. For shorthand, refer to
inter-process messages which have some application meaning as IPC
(inter process communication).
On the first point, IPC is something that the amiga lacks, and surely
needs. A standard for receiving--and sending--messages and a library
or device (or "server") to support this would be a great contribution.
There is no reason, however, to think of AREXX as the only program to
be sending such messages. For example, if a 3-d object editor saves
a videoscape 3d file to ram: and sends a message to videoscape to
render it, there is no rexx in the picture. As another example,
I would like a PD (i.e., free) message sender/macro language ,
instead of REXX, to be available. Perhaps with a graphical interface
instead of a more traditional language. (Recall HyperCard.)
Another example: if a spreadsheet program is asked to dump a
section of the spreadsheet to the clipboard, (perhaps for use
by a separate graphics program), when that section is later changed,
perhaps a message of some broadcast type (or routed to the last user
of clipboard data?) could be sent out as notification. The graphics
program could acquire the new data and be well on the way to
processing the new version of the previous graph in the background, and
even be done before the moment that the user asks to see a graph
of his new figures. Again, no macro language here, just communication
between programs, tuned to the concept of data interchange.
On the second point, my problems are with the description of the
message protocol Bill was proposing at BADGE. First, there is no
"common command set" of messages, such as "create a window," "create
a new 'thing,'" "delete a thing," "refresh a thing," "save a thing,"
or "send me a thing." The reference article for the meeting was
Bill Gates' contribution on "dynamic data exchange" in the BYTE
supplement. DDE has a common command set that would be a start.
The absence of a common command set and some standard examples is one
reason the Amiga clipboard is a practical failure. The protocol
proposal "can transmit anything, it's completely open," but remember the
clipboard can "store anything," as well. An extensible command set is
better than a command set reinvented for each application. Compare
the now standard contents of the "Project" menu.
Secondly, the plan was to send IPC messages to a task's IntuiMessage port.
1) This is not a public port. Intuition does some weird things with
its messages, and probably needs some work in that area.
2) It is better, from a flow of control point of view, and very easy,
to service two ports. The IPC port should be named subject to some clever
conventions, and installed on a system list for public access. Don't
mess with Intuition's problems.
I didn't follow the implementation plans regarding a "Rexx Message Server,"
but I heard more about REXX than about servers in general. For instance,
suppose REXX (or my program) sends a message to a program that is in
the process of closing down. What then? The program may well have
completed clearing its window idcmp port, so any IPC message at that
port is about to get deallocated. A protocol for removing public ports
from access before closing must be sure that messages do not get sent
into space, and that they are always replied.
It was proposed that inter-process data exchange would be accomplished
with these messages, supplanting or in addition to clipboard support.
This is very probably unecessary--the clipboard should suffice--and if
unecessary, a very bad idea.
There was discussion about REXX loading a program if a message was to
be sent to it. I didn't hear enough to know how a program would be
unloaded. What if, in pseudocode: DO 5 TIMES send message to dpaint ENDDO.
Does this load dpaint 5 times?
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.)
On this, I know we would all like to rewrite the AmigaOS from scratch,
but the same reasons we couldn't do it at Commodore-Amiga apply in this
case. And if those reasons need to be re-learned, let's not learn them
at the expense of the IPC potential of the Amiga OS.
This potential is truly great. The excitement over this aspect of
AREXX is well founded, but a little misplaced. The knowledge, talent,
and efforts of the people working with AREXX are indeed critical
to the success of a standard for Amiga IPC. My claims are
that this effort should not be tied to REXX, and that it should
be more sensitive to the existing and future pieces of the system
and the standard problems of IPC such as those I have indicated
above.
I welcome corrections and comments, and general discussion and proposals
for general IPC. If someone can summarize Microsoft's DDE, it might
be food for thought.
jimm
{amiga!pyramid}!mitsumi!jimm
--
Jim Mackraz
Mitsumi Technology, Inc.
{amiga,pyramid}!mitsumi!jimmewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (09/13/87)
** 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
ali@rocky.STANFORD.EDU (Ali Ozer) (09/13/87)
In article <3939@well.UUCP> ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) writes: > 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. At the Desktop Publishing Conference here in Santa Clara Tom Rokicki was showing AmigaTeX, with the newest features. One thing he did was to load a TeX file into (his own REXXified version of) mg, then hit ESC-T. This caused the currently selected region of text to get sent to TeX, which processed the incoming TeX commands and sent them over to the previewer as soon as a page was ready. Thus, you had instant previewing (next best thing to wysiwyg TeX). The communication between the programs was all done with REXX. (For all you TeXies out there, I don't think this version is being released yet, so don't ask him how to get this (like I did 8-) ). But I was happy to finally see REXX in action (as at the BADGE meeting we hadn't seen it actually working). Of course, the above could've been possible without the use of REXX as well. He would've still needed to hack up mg a bit. But, with REXX, you have the capability to talk to any REXX compatible program, and any other editor (TxED, for instance, which I understand has a REXX port?) could be used to replace mg. Or that's what it sounds like to me. > Assuming it *is* just a smart pipe, then I think it should be >written as a device in the AmigaDOS filespace (like, maybe, REXX:). That's the problem I see with REXX --- If it sells as a seperate commercial product, I can't see it getting too successful. (A label on the package says "Requires 512K Amiga, 1.2 KickStart. AREXX recommended.") And what happens when the user gets REXX? "Copy the AREXX program from the REXX disk to your TeX disk. Then edit your startup-sequence file and..." Maybe every developer that wants to use it should get a license to include it with his/her program? That's a bit messy too. You can also understand the author's attempt at making money off the program (he's also the person who brought us conman). Maybe C-A should look at the product, and if they decide it's useful and worthwhile enough, they should buy all rights to it? No? Any solutions? Ali Ozer, ali@rocky.stanford.edu
peter@sugar.UUCP (09/14/87)
In article <267@mitsumi.UUCP>, jimm@mitsumi.UUCP (Jim Mackraz) writes: > start-up code. The WB environment was described as inadequate, without > justification. (Slurs against the CLI environment need no further > justification.) Well I, for one, would like to see some justification for slurs against the CLI *program* environment. It seems to be pretty much a superset of the WB one. I don't know about you, but I like having standard input and standard output around... Now, it might be too hard to emulate. Apropos of which... Since you seem to know so much about it: how do you use Execute to run a CLI program in a window and actually get control back when the program finishes? I always end up with a CLI hanging around until I do and ENDCLI. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)
UH2@PSUVM.BITNET (Lee Sailer) (09/14/87)
One side issue. REXX is the name of the IBM mainframe equivalent of
Unix shell script programming. Maybe y'all can think of a differnt
name for this beast?
peter@sugar.UUCP (09/15/87)
> [LEO describes a great device, REXX:]
Hey, Leo, I love it, but...
why not try to take advantage of the wealth of UNIX-based and UNIX-type
filters already around.
First of all, PIPE: should be able to do the job:
Save as "PIPE:name1"
In your CLI do "2> rexx <pipe:name1 >pipe:name2 using programname".
In your editor read "pipe:name2".
not so hot, is it. OK, do this...
Save as "CLI:name2/rexx using programname".
CLI: would talk to a CLI through a randomly named pipe and start up a CLI
with Input()=randompipe and Output()=PIPE:name2.
It's gotta be possible. Matt Dillon's DTERM does it.
Then you can do this:
Save as "CLI:awk/awk 'something_awful { and more awkward junk }'".
To handle cases when you want to read again from the same program you just
wrote, add an alternate name "BUFFERCLI:" or "TANK:".
Thanks for the idea... I know some people realy dump on the CLI... but
since it's there, why not use it?
--
-- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter
-- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)cmcmanis%pepper@Sun.COM (Chuck McManis) (09/15/87)
In article <20098UH2@PSUVM> UH2@PSUVM.BITNET (Lee Sailer) writes: >One side issue. REXX is the name of the IBM mainframe equivalent of >Unix shell script programming. Maybe y'all can think of a differnt >name for this beast? The point being that AREXX is *just like* REXX on the IBM mainframes. This was the whole point of it in the first place. So if you know REXX you know AREXX and vice versa sort of. I get the feeling that what I think REXX is, what Leo thinks it is, and what Jim think it is are all different and all wrong. We have a definite marketing problem here. [I've never used REXX on a mainframe, but friends I trust assure me AREXX is just like it]. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
peter@sugar.UUCP (09/16/87)
In article <581@rocky.STANFORD.EDU>, ali@rocky.STANFORD.EDU (Ali Ozer) writes: > Of course, the above could've been possible without the use of REXX as well. > He would've still needed to hack up mg a bit. But, with REXX, you have the > capability to talk to any REXX compatible program, and any other editor > (TxED, for instance, which I understand has a REXX port?) could be used to > replace mg. Or that's what it sounds like to me. Why re-invent the wheel? Pipes have been shown over the past 13 years to be a reliable and convenient way of providing filters for all manner of disparate applications. The same thing is available to every one of you, right now, using the "save to pipe" capability in vnews. You can take this message and feed it through an awk program, or a while pipeline, just by entering: s|program<CR> Why not do the same thing in an analogous manner on the Amiga? The named pipes are already there. The only thing you need to do is set up a more convenient method for the user to deal wit them. I don't really think that my suggestion of CLI: is the last word on the subject, but I think it's the direction we need to be going. > That's the problem I see with REXX --- If it sells as a seperate commercial > product, I can't see it getting too successful. (A label on the package > says "Requires 512K Amiga, 1.2 KickStart. AREXX recommended.") And what > happens when the user gets REXX? "Copy the AREXX program from the REXX > disk to your TeX disk. Then edit your startup-sequence file and..." How about writing a REXX program to edit startup-sequence? > Maybe every developer that wants to use it should get a license to include > it with his/her program? That's a bit messy too. You can also understand > the author's attempt at making money off the program (he's also the > person who brought us conman). I think everyone should have the right to make money off it. Perhaps he can release a subset version of REXX with the TeX preprocessor hardcoded into it to be released with TeX, and charge for the full blown version? Conman is still a disappointment to me. It's PD, but the source is in assembler which pretty much precludes easy hacking. It doesn't have the features I would find desirable (adding menus and function keys via escape sequences, a-la ANSI.SYS on the IBM-PC), and I don't have the time to waste on 68000 assembly. I bought this machine so I could avoid assembly language. Has anyone done a driver in Aztec 'C' v3.4? All the examples and PD versions I've seen have been Lattice-based. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)
peter@sugar.UUCP (09/16/87)
In my previous article where I said "I think everone should have the right to make money off of it", I meant to say "I think everyone should have the right to make money off their software". I did not intend to suggest that REXX or CLI: or whatever become some sort of pyramid scheme. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)
peter@sugar.UUCP (09/16/87)
> > That's the problem I see with REXX --- If it sells as a seperate commercial > > product, I can't see it getting too successful. (A label on the package > > says "Requires 512K Amiga, 1.2 KickStart. AREXX recommended."). How about a REXX runtime package, that the developer can link with a pre- compiled REXX program or programs? The user gets the right to run REXX the way the devloper set up, but not write his own programs. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush)
daveh@cbmvax.UUCP (Dave Haynie) (09/17/87)
in article <765@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) says: > Summary: REXX Runtime > >> > That's the problem I see with REXX --- If it sells as a seperate commercial >> > product, I can't see it getting too successful. (A label on the package >> > says "Requires 512K Amiga, 1.2 KickStart. AREXX recommended."). > > How about a REXX runtime package, that the developer can link with a pre- > compiled REXX program or programs? The user gets the right to run REXX the > way the devloper set up, but not write his own programs. > -- > -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter > -- 'U` ^^^^^^^^^^^^^^ Not seismo!soma (blush) It seems to me that once the full REXX to Amiga-Application interface is defined and documented, you could have an arbitrary program serving in the REXX server slot just as easily as you could have a REXX client. I think this touches upon some of the stuff that JimM was talking about in relation to REXX. One function of REXX appears to be to provide a standard, BASIC-like macro language that'll function for any program that wants a macro language, as well as between programs that want macro languages. That would certainly ease the job of anyone building a new program, in that they wouldn't have to build yet another macro language into their program, only the message ports or whatever it is that REXX requires. And of course, that helps the user in that he now learns just one macro language, instead of VT100 macro, DPaint Macro, GonzoCalc Macro, HyperWord Macro, etc. And certainly a scaled down run-time REXX would let the developer choose this scheme. But what I see in this is that some kind of standardized port interface to programs give you the choice of macro languages for your programs. Joe Pazooli down the street might be happy with the mini-runtime REXX language as-is. His neighbor's a power-user and will only be satisfied by the full commercial AREXX, which gives him N can't-live-without new powers. I'd probably turn my "almost-works" LISP interperter into a macro language that supports the same protocols. I don't know how tightly coupled the REXX interface is to the specific language that REXX implements is, but certainly what I'm talking about would be possible, given enough forethought. -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The A2000 Guy" PLINK : D-DAVE H BIX : hazy "God, I wish I was sailing again" -Jimmy Buffett
rogerh@arizona.UUCP (09/18/87)
Is REXX written up anywhere? If not, could some kind soul post a brief description? I feel like I've left the dock without a boat in this discussion... Thanks, Roger Hayes rogerh@arizona.edu
OP.DAVIS%SCIENCE@utah-cs.UUCP (09/19/87)
REXX is the Restructured EXecutive, developed by Michael Cowlishaw
then of IBM U.K It's an interpreted, PL/I-like language first used
on IBM's VM/CMS mainframe systems.
Your library may have his summary article 'The design of the REXX
language', IBM Systems Journal, vol 23. no. 4, 1984, or the books
"Modern Programming Using REXX", by Robert P. O'Hara and David Roos
Gomberg, or Cowlishaw's "The REXX Language: A Practical Approach to
Programming", both published by Prentice-Hall in 1985.
Here's an example program from the summary article:
/* This routine removes duplicate words from a string, and */
/* illustrates the use of a compound variable (HADWORD) that */
/* is indexed by arbitrary data (words). */
Justone: procedure /* make all variables private */
parse arg wordlist /* get the list of words */
hadword.=0 /* show all possible words as new */
outlist = '' /* initialize the output list */
do while wordlist !='' /* loop so long as we have some data */
/* split WORDLIST into the first word and the remainder */
parse var wordlist word wordlist
if hadword.word then iterate /* loop again if already had */
hadword.word = 1 /* remember that we have had this word */
outlist = outlist word /* and add this word to output list */
end
return outlist /* finally return the result */
-------peter@sugar.UUCP (Peter da Silva) (09/20/87)
In article <28070@sun.uucp>, cmcmanis@pepper.UUCP writes: > The point being that AREXX is *just like* REXX on the IBM mainframes. Say what? You want to implement an IBoMination on an Amiga? > This was the whole point of it in the first place. So if you know > REXX you know AREXX and vice versa sort of. So you want to implement Yet Another Scripting Language that only a few people know anything about? What's wrong with UNIX-style scripts? Or if you want to go whole-hog, use Xlisp. Modified lisps are one of the most common special purpose languages around (GNU Emacs, ADVsys, etc...). And given the typical memory requirements of IBM-mainframe software, I'd doubt that AREXX would be too handy for us 512K types. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today?
peter@sugar.UUCP (Peter da Silva) (09/23/87)
...which is fast catching on as a more-powerful and portable replacement for AWK? Source code is generally available, and it seems to be everything REXX is and more. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today?
rokicki@rocky.STANFORD.EDU (Tomas Rokicki) (09/24/87)
>> This was the whole point of it in the first place. So if you know >> REXX you know AREXX and vice versa sort of. > So you want to implement Yet Another Scripting Language that only a few > people know anything about? What's wrong with UNIX-style scripts? Or if Few people? There is a huge base of REXX users out there. Unix scripts are fine, as long as you add full awk capabilities as well. > you want to go whole-hog, use Xlisp. Modified lisps are one of the most > common special purpose languages around (GNU Emacs, ADVsys, etc...). And Oh, so now you want to sink the Amiga with those damn parentheses! (I spend most of my time hacking Lisp machines, so I know and love Lisp, but you can keep the damned parentheses.) Seriously, Lisp would be fine, with the proper extensions, but the thing is, REXX exists and works well on the Amiga, and Xlisp doesn't. By works well, I'm talking about for general use as a scripting language and as a inter-process communication medium; all of the necessary hooks, including reentrancy and residence aren't in XLISP yet. > given the typical memory requirements of IBM-mainframe software, I'd doubt > that AREXX would be too handy for us 512K types. Wrong, AREXX is tiny, tiny, tiny. All in crufty hand-coded assembly. Why don't you call Bill Hawes and talk to him about it? -tom
peter@sugar.UUCP (Peter da Silva) (09/25/87)
In article <611@rocky.STANFORD.EDU>, rokicki@rocky.STANFORD.EDU (Tomas Rokicki) writes: > > So you want to implement Yet Another Scripting Language that only a few > > people know anything about? What's wrong with UNIX-style scripts? Or if > Few people? There is a huge base of REXX users out there. Unix > scripts are fine, as long as you add full awk capabilities as well. There a huge base of IBM-mainframe types out there who know REXX. Most people with Amigas, however, are more likely to be frustrated UNIX fans. > > you want to go whole-hog, use Xlisp. Modified lisps are one of the most > > common special purpose languages around (GNU Emacs, ADVsys, etc...). And > Oh, so now you want to sink the Amiga with those damn parentheses! Actually, I've changed my mind on this. I've decided I want to use ICON. I've had enough BASIC like and PL/1 derived languages to last me a couple of lifetimes. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- 'U` Have you hugged your wolf today? -- Disclaimer: These aren't mere opinions... these are *values*.
grr@cbmvax.UUCP (George Robbins) (09/26/87)
In article <822@sugar.UUCP> peter@sugar.UUCP (Peter da Silva) writes: > In article <611@rocky.STANFORD.EDU>, rokicki@rocky.STANFORD.EDU (Tomas Rokicki) writes: > > > So you want to implement Yet Another Scripting Language that only a few > > > people know anything about? What's wrong with UNIX-style scripts? Or if > > Few people? There is a huge base of REXX users out there. Unix > > scripts are fine, as long as you add full awk capabilities as well. > > There a huge base of IBM-mainframe types out there who know REXX. Most people > with Amigas, however, are more likely to be frustrated UNIX fans. The person who wrote AREXX is one of those mainframe types who happens to also be interested in the Amiga and felt the lack of one of the few (my opinion) nice features of the IBM operating system/editor arrangements. Now it may well be that it doesn't appeal to you, in which case you are free to to a better job, however it seems that you have been criticising AREXX on general principles without bothering to find out what it is really all about... -- George Robbins - now working for, uucp: {ihnp4|rutgers|allegra}!cbmvax!grr but no way officially representing arpa: out to lunch... Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
randy@bcsaic.UUCP (Randy Groves) (09/27/87)
Is this product out yet??? Any info on what it will cost? I haven't hacked REXX since working on IBM maintrash a few years ago, but it looked good. -- -randy groves - Boeing Advanced Technology Center UUCP: ..!uw-beaver!uw-june!bcsaic!randy USNail: Boeing Computer Services CSNET: randy@boeing.com PO Box 24346 M/S 7L-68 VOICE: (206)865-3424 Seattle, WA 98124
toebes@sas.UUCP (John Toebes) (09/29/87)
In article <774@sugar.UUCP>, peter@sugar.UUCP (Peter da Silva) writes: > In article <28070@sun.uucp>, cmcmanis@pepper.UUCP writes: > > The point being that AREXX is *just like* REXX on the IBM mainframes. > Say what? You want to implement an IBoMination on an Amiga? Actually if you look at the history of REXX on CMS, it succeeded because it was so good - not because of IBM. From rumors of its origins I understand that IBM did not want to release it but it got so much flak internally that it decided to make a product of it. > > This was the whole point of it in the first place. So if you know > > REXX you know AREXX and vice versa sort of. > So you want to implement Yet Another Scripting Language that only a few > people know anything about? What's wrong with UNIX-style scripts? Or if REXX is not just another scripting language. It was designed from the ground up to talk to programs unlike the UNIX-style scripts which simply acts as an intelligent pipe. This is not intended to start Yet Another MY-LANGUAGE-IS-BETTER-THAN-YOURS Holy wars, but to point out that you should research the item in question before taking pot-shots at it. > you want to go whole-hog, use Xlisp. Modified lisps are one of the most > common special purpose languages around (GNU Emacs, ADVsys, etc...). And > given the typical memory requirements of IBM-mainframe software, I'd doubt > that AREXX would be too handy for us 512K types. This is the place where you are the most wrong. Bill has coded the entire thing from the ground up in highly tuned assembly language! He has to the best of my knowledge implemented the first truely MULTI-TASKING program control intelligent script language. It uses some of the best features of the Amiga including libraries and global message ports to give the greatest flexibility in communication with REXX and with other programs that use the REXX interface. Furthermore, he has designed and thought out quite carefully the communications interface so that you could implement even your own script language that talks to any of the programs comming out to take advantage of the REXX interface. > -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- |_o_o|\\ John A. Toebes, VIII usenet:..mcnc!rti-sel!sas!toebes |. o.| || | . | || Coordinator of ... | o | || The Software Distillery | . |// USnail: 235 Trillingham Ln, Cary NC 27511 ====== BBS: (919)-471-6436
peter@sugar.UUCP (09/30/87)
The last thing the Amiga needs is another programming environment, with more hooks that people have to make to their programs if they want them to be competitive. One of the things Apple did right was force developers to stick to the standard user interface. The Amiga has two standard interfaces right now: the workbench, and the CLI. I like this, although I think that it could have been done without forcing two programming environments on people (yes, I know something about the history behind it and understand that there really wasn't much in the way of alternatives). In any case people should be encouraged to develop tools and applications that fit in with the existing CLI and Workbench unless there's an overriding reason not to. REXX as a script language is probably really useful for some people... maybe even me. REXX as a new programming environment with custom ports and stuff is overkill. REXX as a device (REXX:) is better. It's still not perfect, because maybe other scripting languages would be better for other people (icon, or awk, or sed, or...). What's wrong with a CLI:? Finally I think people at C=, and C= in all its corporate glory, should be discouraging people from making the Amiga even more of a mishmash of operating systems than it is. While encouraging people to develop standard tools and applications that fit well together, of course. Instead of discouraging people who are trying to keep what conceptual integrity remains intact. da Silva's law #2^n-1: don't be different just for the sake of being different. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
mlm@ncsuvx.ncsu.edu (Mike McMullen) (10/01/87)
This discussion on AREXX and scripting languages is getting out of hand. Whats the big deal anyway? I work as a systems programmer in a multi-machine environment. I do work on VM/CMS, VMS, and Ultrix each of which has a different scripting language. There are features in all scripting languages that work elegantly for some given application. On the Amiga I think it would be great if I could have my choice of script language for a given application. Instead of everyone saying this is the script language I should use, let ME pick what I want to use. C= provides CLI scripts. If I want something that I can be sure will work on anyone else's machine I can use a CLI script or I can provide a disk that sets up my applications environment that people can copy or let them integrate my environment into their setup. Personally, I find REXX for the Amiga exciting. Hopefully I can take some of my execs off of our IBM machine and run them on my Amiga. This type of capability makes the Amiga more interesting for the dye in the wool IBMers. This makes my life easier on pushing C= stuff on campus because it can appeal to a wider audience. What I'm starting to read here is my script language is better than yours type jazz when we are comparing apples to oranges. Let the developer decide what he wants! Well now who is interested in writing DCL for the Amiga? ;-) Mike McMullen NCSU Computing Center Raleigh, NC mlm@ncsuvx.ncsu.edu
rokicki@rocky.UUCP (10/01/87)
> The last thing the Amiga needs is another programming environment, with > more hooks that people have to make to their programs if they want them > to be competitive. One of the things Apple did right was force > developers to stick to the standard user interface. The Amiga has two > standard interfaces right now: the workbench, and the CLI. I like this, > although I think that it could have been done without forcing two > programming environments on people (yes, I know something about the > history behind it and understand that there really wasn't much in the > way of alternatives). I disagree. The Amiga certainly needs a standard for communication among programs, one that the global single clip-board does not address. Because the applications that will be interfaced cannot be forseen, it should be programmable, preferably by the user. The Amiga also needs a standard macro language that all applications can share, once again, user programmable. Then only one macro language need be learned, and everyone is happy. One thing that must be understood is that there are different levels of users. The novice feels right at home with the workbench, because of its visual nature. Expert users usually feel encumbered by the workbench; it is much faster to type a command than to point and click, point and click, oh, there's the program, point and click. I think putting both interfaces on the Amiga was a major win. But we still need a scripting language; the CLI stuff just isn't smart enough. Every major operating system that I know about has developed a powerful scripting language; Unix has shell, IBM has REXX, VMS has DCL, etc. One of the uses of this scripting language, of course, is to present a cleaner interface to the end user. > In any case people should be encouraged to develop tools and > applications that fit in with the existing CLI and Workbench unless > there's an overriding reason not to. REXX as a script language is > probably really useful for some people...maybe even me. REXX as a > new programming environment with custom ports and stuff is overkill. > REXX as a device (REXX:) is better. It's still not perfect, because > maybe other scripting languages would be better for other people > (icon, or awk, or sed, or...). What's wrong with a CLI:? People should definitely build tools that work with CLI and Workbench. But there are many things that cannot be done with CLI or Workbench. The thing is, REXX should be there if you need it; if you don't, good, don't use it. Other people will. Why is REXX with custom ports overkill? I don't understand that at all. If you think REXX would be good as a device, you are missing the main point of REXX. How can a device invoke primitives from a program? Normally, a device acts strictly as a slave to a program; REXX and a program can interact at different levels, with the program as a slave to REXX, vice versa, or with the two of them communicating much more on a peer basis. Other scripting languages will always be good for other people. But, REXX exists, works well in the Amiga environment, and gives one an incredible amount of power. Today. > Finally I think people at C=, and C= in all its corporate glory, should > be discouraging people from making the Amiga even more of a mishmash of > operating systems than it is. While encouraging people to develop > standard tools and applications that fit well together, of course. And what better way to encourage standard tools and applications that fit well together, then by proscribing and supporting a standard and programmable means of communication among tasks? This is a problem that won't go away be pretending it doesn't exist, Peter; until a standard is agreed upon, people will continue to write non-cooperative tools or tools that cooperate in incompatible ways. It's really that simple. > Instead of discouraging people who are trying to keep what conceptual > integrity remains intact. The conceptual integrity shall remain intact, perfectly intact. It will just be made more powerful, extended for those of us who need such extensions.
ralph@mit-atrp.UUCP (10/02/87)
It was mentioned that the CLI was for expert users and the workbench
for beginners.
Well.....just to let others like me not feel alone....
I am a serious veteran computer user and I have been valiantly using the
workbench. I only use the CLI when I'm *forced* to by programs that
don't understand icons.
I feel that it's easier to just point to something and drag it to its
new desination instead of typing:
copy df0:stuff/funky/wow vd0:c/test/whoosh
I guess it's all diff'rent strokes for diff'rent fokes.
I realize the Workbench has problems (like slow drawers !),
but I think there's a future in this. Even if I have to fix it.
But anyhow, there are those among us who are not new at computers and
still would rather work in icons. I firmly believe (perhaps alone now)
that I can even *program* in an icon-based language.
Go ahead and laugh....they laughed Galileo, and at Columbus...
we all know the world is rou
n
dtenny@z.dec.com (Dave Tenny | DTN 225-6089) (10/06/87)
Having coded many things in REXX using VM/CMS, and many scripts on Ultrix; I'll take REXX anyday. A good implementation can be really fast, the biggest performance problem on CMS was when you allocated lots of stemmed variables (and de-allocated). I think REXX got tied up in free storage calls. I've always thought perhaps a way to pre-allocate lots of storage in REXX would be useful. If Mr. da Silva would care to declare any REXX experience, I'll be happy to take his Unix religion with more than a grain of salt. I'd love a REXX for the Amiga! Dave Tenny VAX LISP development. (Please won't somebody write Common Lisp for the Amiga...)
rokicki@rocky.STANFORD.EDU (Tomas Rokicki) (10/08/87)
[ Oh, by the way, this is the fellow who brought you Conman. ] AREXX will be available by October 14th from: William Hawes PO Box 308 Maynard, MA 01754 (617) 568-8695 $49.95 includes a 150 page manual, header files for use of REXX facilities within applications, and the REXX software itself. Feel free to call Bill if you have any questions. -tom
peter@sugar.UUCP (Peter da Silva) (10/12/87)
OK, so maybe REXX is an exception to the VM/CMS==huge and slow rule. And I'll admit I shouldn't be knocking new programming languages (new to the Amiga, anyway). But why implement it in such a weird way? If you want to take advantage of REXX (and I might be wrong about this... it's been known to happen) you have to handle a thing called a REXX port... presumably another message port... in your program. And when you do, you can't use it to take advantage of any other filters than REXX. Making it a device that can be addressed through AmigaDOS (as some have suggested) would be an improvement. Better still would be to make it possible for other filters to be plugged in. Now, most any program you want to use as a filter is going to have the ability to read from Input() and write to Output() (except for REXX, apparently). Programs like awk and sed that have proven useful over the years. Newcomers like icon. Quicky programs that even novice programmers can turn out quickly in whatever language they like to do strange and bizzarre things to data. Before going off in a new direction, how about looking at an environment that has been using filters with great success for many years... ...instead of setting up another clipboard. Look how useful that's been. -- -- Peter da Silva `-_-' ...!hoptoad!academ!uhnix1!sugar!peter -- Disclaimer: These U aren't mere opinions... these are *values*.
daveh@cbmvax.UUCP (Dave Haynie) (10/12/87)
in article <11774@decwrl.DEC.COM>, tenny@z.dec.com (Dave Tenny | DTN 225-6089) says: > > If Mr. da Silva would care to declare any REXX experience, > I'll be happy to take his Unix religion with more than a grain of salt. I've never actually used REXX, and I've used UNIX shell, DCL, the Amiga script language, and a few others. After glancing through the AREXX manual yesterday, I can state with certainty that as a scripting language alone it's going to be much more powerful than any of the others I've yet seen (actually, there was one they were developing on the DEC-20s at CMU to replace the standard TOPS script language, though I haven't seen it anywhere else). That's not even considering the much tighter coupling you can get if a program specifically uses AREXX as a macro language. By the way, this is the only thing IBM that I've ever liked. PC-DOS, XEDIT, etc. are the worst of their type as far as I'm concerned. They got so many things wrong it just stands to reason that they must have done something right. I think REXX must be it. > Dave Tenny > VAX LISP development. > (Please won't somebody write Common Lisp for the Amiga...) ^^^^^^^^^^^^^^^^^^^^^^^^^ I'll second that one! -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|caip|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "Computers are what happen when you give up sleeping" - Iggy the Cat
randy@bcsaic.UUCP (Randy Groves) (10/15/87)
In article <2472@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >in article <11774@decwrl.DEC.COM>, tenny@z.dec.com (Dave Tenny | DTN 225-6089) says: >> (Please won't somebody write Common Lisp for the Amiga...) > ^^^^^^^^^^^^^^^^^^^^^^^^^ >I'll second that one! > Thirds! Thirds! And while you're about it put in CLOS, the Common Lisp Object System (ya, I know, I'll have to get a LOT more memory!!!). Anybody listening? Also how about an object system for C. Does anybody know whether C++ or Objective C are available for the Amiga?? -- -randy groves - Boeing Advanced Technology Center UUCP: ..!uw-beaver!uw-june!bcsaic!randy USNail: Boeing Computer Services CSNET: randy@boeing.com PO Box 24346 M/S 7L-68 VOICE: (206)865-3424 Seattle, WA 98124
mwm@eris.BERKELEY.EDU (Mike (My watch has windows) Meyer) (10/18/87)
In article <2409@bcsaic.UUCP> randy@bcsaic.UUCP (Randy Groves) writes: <In article <2472@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: <>in article <11774@decwrl.DEC.COM>, tenny@z.dec.com (Dave Tenny | DTN 225-6089) says: <>> (Please won't somebody write Common Lisp for the Amiga...) <> ^^^^^^^^^^^^^^^^^^^^^^^^^ <>I'll second that one! <> < <Thirds! Thirds! And while you're about it put in CLOS, the Common Lisp <Object System (ya, I know, I'll have to get a LOT more memory!!!). < <Anybody listening? Yeah, I'm listening. CL is one of my projects for right after this one (you know how that goes...). Anyway, since the best way to get something done is to get someone else to do it or you, I'll make an offer: Kyoto Common LISP (KCL) is C-sourced implementation of Common LISP for Unix systems. My quick glance at it shows that it should be portable to Amigas without great amounts of pain. I'm willing to download and mail Amiga floppies to anyone who's interested enough to mail me blank floppies in the first place. Of course, the offer for CScheme 5.0 still stands. <mike -- The handbrake penetrates your thigh. Mike Meyer A tear of petrol is in your eye. mwm@berkeley.edu Quick, let's make love before we die. ucbvax!mwm On warm leatherette. mwm@ucbjade.BITNET
craig@unicus.UUCP (10/20/87)
In <2409@bcsaic.UUCP>, randy@bcsaic.UUCP (Randy Groves) writes: >In article <2472@cbmvax.UUCP> daveh@cbmvax.UUCP (Dave Haynie) writes: >>in article <11774@decwrl.DEC.COM>, tenny@z.dec.com (Dave Tenny | DTN 225-6089) says: >>> (Please won't somebody write Common Lisp for the Amiga...) >> ^^^^^^^^^^^^^^^^^^^^^^^^^ >>I'll second that one! >> > >Thirds! Thirds! And while you're about it put in CLOS, the Common Lisp >Object System (ya, I know, I'll have to get a LOT more memory!!!). Fourths. I didn't know that the Common Lisp Object System had actually been specified, I thought Symbolics, Xerox, etc., were still bickering. I thought Common Loops had the edge in this battle, but what happened ? As to the memory, an A2000 with 16 megs RAM and some 10 meg SCSI floppies to back up the partition (oh, and leave 6 meg for ramdisks and incidentals) ought to be able to do it. Most Lispmachines don't have an MMU, either. But it ought to have a 68000 with 68881 at least at 16 MHz. With a good monitor, you might be talking about $5000 for the whole thing in about a year when: (monitor=$500, CPU+RAM=$1500, A2000=$1000, LISP=$2000) with real-live support, etcetera. That's a hell of a lot cheaper than a Xerox D-Machine or a Symbolics box. And probably not much slower. >Anybody listening? Hopefully. To be the first microcomputer true workstation would be more than worthwhile. CAD/CAM, AI, and other fields are screaming for this. It's pretty difficult to do proper research when you can't afford the workstations. >Also how about an object system for C. Does anybody know whether C++ or >Objective C are available for the Amiga?? I don't, but the C++ compilers supposedly compile to C code, at which point, any standard C compiler *should* be able to use it. Possibly with some global search/replaces for funny file names. I think you'd only have to construct some dummy libraries that looked like Exec, etc. on the C++ box. If I'm all wet about this, someone please correct me and accept my apology. Of course, if you want to work with C++ *ON* your Amiga, it'll be a while. Though I expect to see it before a decent Common Lisp. Craig Hubley, Unicus Corporation, Toronto, Ont. craig@Unicus.COM (Internet) {uunet!mnetor, utzoo!utcsri}!unicus!craig (dumb uucp) mnetor!unicus!craig@uunet.uu.net (dumb arpa)