🚀 go-pugleaf

In article <896@nuchat.UUCP>, peter@nuchat.UUCP (Peter da Silva) writes:
> In article ... kim@amdahl.uts.amdahl.com (Kim DeVaughn) writes:
> > I hadn't really thought about posting it, until Peter da Silva catagorized
> > the REXX language as being "PL/I like".  Bunk.
>
> It's PL/1-like. I've extensive experience with another PL/1 derivitive
> (namely PL/M), and moderate experience with PL/1 itself (despite my best
> attempts at avoiding it :->).

Fine.  *I* find it to be closer in flavor to elementary C code, than to PL/I.
It's really quite different than either, so this discussion is pretty
pointless (and therefore, I won't comment on it further in future postings).

I will say that (as with any language), there are a number of things I *don't*
like about the REXX language.  I'll put up with them though because of all of
the flexibility and capability the ARexx *package* gives me.


> There's nothing inherently wrong with being PL/1-like, so don't be so
> defensive. I just happen to prefer weird C derivitives.

Not defensive.  I personally find PL/I to be a disgusting language, that I've
had to deal with alot more than I would have cared to.  BTW, I assume we're
talking about the same language ... PL/I.  I've never used anything called
PL/1 ... :-)


> > say "Cuckoo at" zhour||":"||xmin
>                  ^ Don't you want a concatenation operator here?

No.  The space is a concatation operator, which (logically enough) gives
you: the LHS of the expression, a space, and the RHS of the expression.
REXX, you see, is a language oriented toward text processing, and has several
features that facilitate this.  It this instance, you really aren't aware that
an operator is being used, unless you think about it.

Another point ... the explicit || concatenation operators aren't really needed
here at all.  Bob just used them for clarity.  REXX is flexible enough that
there are often several ways to specify the same action.  There *are* cases
where the || operator is needed, BTW.


> > else do
> >   tmin=xmin%10
> >   if tmin=1 then do;
>                      ^ Isn't this redundant?

Yeah.  Doesn't hurt anything though.  Sorta like C lets you code: if (foo) {x++;}
where the braces are redundant.


> > if opt="ALARM" then address COMMAND speak dingaling
>                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Mind explaining this
>                                                       construct?

Glad you asked.  You are looking at one of the reasons why ARexx and the REXX
language is so well suited to serve as a script/macro/IPC processing hub.

REXX uses the concept of an "address" to determine who should process a given
command.  The above form is a very explicit way of telling the interpreter that
this command is for the OS (that's what "command" specifies ... the OS).  In
this example, what gets passed to AmigaDOS for execution is:

    "Mumble ggggggggggggggggggg"

due to the assignments made for "speak" and "dingaling" (mumble is the stripped-
down, assembly language version of the AmigaDOS "say" command that was posted
along with this example).  This is important to note: the commands that are
to be passed to an external program (OS, or whatever), can be coded as REXX
*expressions*, and not merely specified as a hard-coded string.  Flexible.
And powerful.

Had this been *my* code, I might well have just put the REXX statement
"address command" up at the top of the REXX program, and then I could have
just written:  if opt="ALARM" then speak dingaling   and it would've worked
in the same way.   I.e., the REXX interpreter dosn't understand "Mumble" as
a command, it sees that the "address" has been set to "command", and so
passes it on to the OS, assuming that it (the OS) will know what to do with
it.  If the OS *doesn't* know, you get an error back (command not found, etc).

Of course the "address" specified could have been any application set up to
talk to ARexx, so you could say "address TXED", or "address DME", etc. and
passed commands to those applications just as easily.

Also, if the REXX program had been invoked *from* such a host  (i.e., as a
macro), there is no need to use the "address" command at all to issue commands
back to that host, as the interpreter keeps track of who the invoking program
was.  Anything it (the interpreter) doesn't understand gets passed back to the
invoking host by default.  Or you can change where it goes.

Start to see how (from the user's point of view) multiple applications can
*communicate* (and not just pass data)?

There are a number of other nuances that the "address" statement has, one of
which is to allow the address itself to be specified by an expression, and
not hard-coded.  Another is a "toggle" form, that swaps between the current
and previous addresses.  Etc.


I really suggest you take a look at Cowlishaw's book that defines the REXX
language:

       "The REXX Language"
       "A Practical Approach to Programming"
        M. F. Cowlishaw
        Prentice-Hall, 1985

Should be able to find it in your local university library, or a decent computer
book store.

Or, better yet, get a copy of ARexx from Bill Hawes, and *find out* what it can
and cannot do!  Then you might be in a position to offer comments that have some
substance to them, and not just your own personal opinions, most of which seem
to be based on mere conjecture.


BTW, for those of you also running MS-DOS on the Bridge, or a PClone, a REXX
interpreter is also available for that system from Mansfield Software.  Of
course it doesn't have quite the capabilities that ARexx provides, since
it's not running on a multi-tasking, message-passing system.  If interested,
email me, and I'll hunt up their address.

/kim


-- 
UUCP:  kim@amdahl.amdahl.com
  or:  {sun,decwrl,hplabs,pyramid,ihnp4,uunet,oliveb,cbosgd,ames}!amdahl!kim
DDD:   408-746-8462
USPS:  Amdahl Corp.  M/S 249,  1250 E. Arques Av,  Sunnyvale, CA 94086
CIS:   76535,25