Xref: utzoo comp.sys.amiga.tech:208 comp.sys.amiga:17434 Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!oliveb!amdahl!kim From: kim@amdahl.uts.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga.tech,comp.sys.amiga Subject: Re: A small ARexx example, and other useful tidbits . . . Message-ID: <27345@amdahl.uts.amdahl.com> Date: 9 Apr 88 23:32:05 GMT References: <26223@amdahl.uts.amdahl.com> <896@nuchat.UUCP> Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 130 Keywords: Warning: also contains a small assembly language example! 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