Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!zaphod.mps.ohio-state.edu!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!hal!ncoast!davewt
From: davewt@NCoast.ORG (David Wright)
Newsgroups: comp.lang.rexx
Subject: Re: REXX: What is it? (AREXX)?)
Keywords: REXX
Message-ID: <1989Dec13.222001.10720@NCoast.ORG>
Date: 13 Dec 89 22:20:01 GMT
References: <1585@bnlux0.bnl.gov> <1989Dec10.203627.10443@NCoast.ORG> <[25835d33:21.3]comp.lang.rexx;1@tronsbox.UUCP> <5888@alvin.mcnc.org> <1989Dec12.160943.16118@psuvax1.cs.psu.edu> <1989Dec12.211158.25536@NCoast.ORG> <1989Dec12.235944.7970@psuvax1.cs.psu.edu>
Reply-To: davewt@ncoast.ORG (David Wright)
Organization: North Coast Public Access UN*X, Cleveland, OH
Lines: 40

In article <1989Dec12.235944.7970@psuvax1.cs.psu.edu> schwartz@psuvax1.cs.psu.edu (Scott Schwartz) writes:
>In reply to someone claiming REXX supported all known 
>control structures, I wrote:
>>>Not really...  It doesn't have continuations (like Scheme or
>
>I disagree.... while you could write a simulator for Scheme or /bin/sh
>in REXX, it's not the same as being able to do certain operations
>directly in a REXX program.  Certainly the things I mentioned are
>nothing like external routines written in other languages; they require
>features REXX simply has no conception of.
>
>Anyway, let's not get carried away with this.  REXX is a fine language;
>not supporting every known control structure is nothing to be ashamed
>of!

	You obviously have never really USED Rexx, or any other extensible
language. Your argument that because it doesn't do something "out of the
box", Rexx must be lacking something is completely wrong.
	As any FORTH programmer can tell you, what comes out of the
box is just the beginning. The only limits to ANY language are the real,
factual, limitations of the implementation.
	Now if Rexx did not really support the writing of modules in other
languages, and these additions were just "patch jobs", you would be at least
half right. But in many implementations of Rexx (and I suspect all), the
commands are NOT resident in one piece, but consists of a combinations of
other Rexx macros AND some executable data. What is this executable data
written in? Usually C or some other language.
	Adding in new sub-modules to Rexx is part of working with it.
Unlike shell scripts, where the output of other programs is pretty limited
in how it may be returned to the shell script, Rexx programs can INTERACTIVELY
exhange data with other Rexx programs or completely different programs which
have Rexx "ports" for communication (similar to BSD named pipes).
	This is not outside the normal way of interacting with Rexx, and
many Rexx programmers (myself included) gradually build up a small
library of functions that we use when building new Rexx applications.
	To judge modern or by definition extensible langues such as
Rexx or FORTH with the same standards used for more limited languages such
as BASIC, Fortran, or COBOL is like comparing apples and oranges. The
whole underlying philosophy of the structure of the language is different,
and requires a different mind-set to work with it.