[comp.lang.rexx] A Suggestion For Adding Function Pointers To REXX

Will@cup.portal.com (Will E Estes) (01/02/90)

In the AREXX-L conference a user made the comment:
< I agree, the expose facility just isn't good enough. On the other hand,
< I don't think that pointers are the right answer for this problem.
< Generally, I think that the most serious fault in REXX is the fact that
< you CAN'T pass compound variables as arguments (anyway, I haven't been
< able to do so).  Neither is returning stem variables supported. If this
< omission were fixed, I think that one could do without pointers.

Okay!  So let's make an attempt at coming up with a reasonable
syntax/semantics for a facility that approximates pointers in
REXX.  Others please jump in and improve on this.  You just never
know who may be watching this, and it might just end up in a
commercial product someday.  For REXX newcomers: none of the code
that follows is real REXX.  So don't try to use any of the
following.  It won't work with REXX as it stands today.  I'm just
trying to get people thinking about how REXX could be changed to
get some of the sophistication that pointers add to a language
like C.

Now, the suggested changes to REXX:

(i) use & to mean that you are passing the name - not the physical
address - of a variable or node and * to mean that you are
receiving the name into a variable or stem.

(ii) & in combination with () would mean that you are passing the
name - not the physical address - of a function and * in
combination with () would attempt to execute a function by
reference.  Function invocations through the *() mechanism could
be through stems as well as variables (to allow for tables of
function pointers).

Here are some examples:


                    Example I

/* some code to pass a variable by reference in REXX
 */
call test parm1 &parm2
...
test:procedure
parse arg NewParm1 *NewParm2
...

So in the above example NewParm1 is a local variable, and NewParm2
is NOT local to the test subroutine.  It points to the same data
area referenced by parm2.  Changes made to NewParm2 in the test
subroutine change parm2 even after the test subroutine finishes
executing.


                    Example II

/* some code to pass an arbitrary node in a stem to another stem
 */
call test parm1 &OriginalStem.down.the.tree.
...
test:procedure
parse arg parm1 *NodePseudoPointer.
...

So in the above code NodesPseudoPointer would point to the node of
OriginalStem that begins at the level of tree.   So
issuing the statement:

NodePseudoPointer.id.3 = 'NewValue';

would be the same as issuing the statement:

OriginalStem.down.the.tree.id.3 = 'NewValue';

outside of the test subroutine.


                    Example III

/* some code to return a stem
 */
*ReturnedStem. = test()
...
test:procedure
...
return &SomeStemIWantToReturn.


                    Example IV

/* some code to build a table of function pointers
 */
FuncPointers.1 = &test1()
FuncPointers.2 = &test2()
FuncPointers.3 = &test3()
...
*FuncPointers.keypressed()  /* invokes the function that
                             * corresponds to the key that
                             * was pressed
                             */

So, anyway, does this work?  Would others find this sort of change
to REXX useful?  Are there other ways of accomplishing the same
thing that would be better?

Thanks,
Will              (sun!portal!cup.portal.com!Will)

cosc6bp@elroy.uh.edu (A JETSON News User) (01/16/90)

Ummm, I don't think that using & is such a good idea.  One reason is that
IBM's EXEC and EXEC2 languages required you to use &'s in front
of variable names.  It was messy.  REXX was a vast improvement on the EXEC 
languages and the fact that you didn't have to use &'s was one of the reasons
it became such a success.  However, the need for pointers, or a pointer 
substitute is a good idea.

Ignacio Valdes 

Will@cup.portal.com (Will E Estes) (02/02/90)

A month ago I made a suggestion to this list that REXX needed a
capability that approximates pointers in C in terms of its
functionality.  I suggested a mechanism for adding both function
and data pointers that involved passing a reference to variable or
function (but NOT the actual machine address).

There were a lot of good responses to the original posting, and I
want to summarize the responses and try to give answers.  Be forewarned
that this posting runs about 200 lines before you start reading.

First, to review, my original suggestion for a modified syntax and
semantics was as follows:

(i) use & to mean that you are passing the name - not the physical
address - of a variable or node and * to mean that you are
receiving the name into a variable or stem.

(ii) & in combination with () would mean that you are passing the
name - not the physical address - of a function and * in
combination with () would attempt to execute a function by
reference.  Function invocations through the *() mechanism could
be through stems as well as variables (to allow for tables of
function pointers).

Why make these changes?  There are several reasons:

1) to allow a way to pass variables, arrays, and arbitrary
*portions* of arrays by reference to a subroutine.  There is
simply no other way to allow REXX to become a language where you
can build general-purpose subroutines that act on a kind of data
rather than hard-coding in the name of a *particular* data
structure through EXPOSE.  I dare anyone to write in REXX a
general purpose binary sort routine that acts on *any* REXX array.
Without some changes to the *language* it can't be done, and I
think that should cause some serious concern to anyone who wants
to use REXX as more than a shell language.

2) to allow a way to *return* arrays, and arbitrary *portions* of
arrays by reference.   There are some problems with the way I
originally suggested doing this, and I'm not convinced of the
utility of it, but it would give a way to return very complex
subroutine results that can't be well-handled by something like:

        parse value MyFunction() with retcode1 retcode2 etc

3) to give you an *elegant* way to build tables of function
pointers. (I don't count use of INTERPRET as elegant because of
its overhead, its absence from the compiler, and because it can
sometimes be difficult to read.)

Here were the responses I received:

Steve Bacher responds:
< First of all, the & and * prefix syntax is fine for C, but won't
< work in REXX.  This is because, in REXX, abutment of expressions
< is a feature of the language.  That this means is that you would
< be introducing an ambiguity.  Consider the statement
<       say foo *bar &baz
< Does this mean to display the value of foo concatenated with the
< value of the expression [foo times bar] logical_and baz  ???

That's a very good point.  Can't argue with it.  & and * will
definitely have to go.  But this is just a syntax ambiguity that
can be easily resolved by choice of a different set of operators.
For now put up with the incorrect symbolism just because of the
fact that it looks familiar to C programmers and for purposes of
this discussion will help out.

< Second of all, exactly what would be the "address" of a REXX
< variable?  When you say "say &myvar", what gets displayed?
< Depending on the implementation, there may not be a "machine
< address" associated with the variable.  In MVS/TSO, for example,
< the REXX variables may get bumped around the tree from statement
< to statement (this is all internal OCO stuff anyhow).

Hold on now.  I specifically said as part of the original
suggestion that & did NOT reference a machine address of any sort.
In fact, what & does reference is not defined at all, and you
should never modify it in any way.  Practically, saying &test
would probably get you a handle.  How that handle is used by the
interpreter is implementation-dependent and is of no concern to
the user.

Ed Nilges responds:

< The trouble here is that you are receiving this information into
< a REXX procedure.  This means that the dereferencing in the
< parse arg statement conceptually takes place outside the "test"
< procedure.

But PARSE ARG currently grabs copies of variables "outside" the
test procedure.  What is so far-fetched about also having it grab
handles to variables and stems at the same time?  It's really a
question of what the language semantics allow for.  The variable
environment that a subroutine works with is a function of the
arguments to a subroutine call and the EXPOSE statement; that is
true both before and after my suggested change, and I don't see
how the new semantics I'm proposing involve a contradiction here.

< While this is probably implementable, it is almost unexplainable
< to all but the REXX aficiando.  I have enough trouble getting
< REXX programmers to use PROCEDURE for good information hiding
< and disciplined use of variables.

Well, I agree most programmers won't use the feature.  The issue
is what features need to be added to REXX to make it fully capable
to do professional-quality applications.  A professional-quality
application assumes a professional-quality programmer,
unfortunately ( :) ).   I would hate to see someone take pointers
out of C just because most programming students don't understand
the concept!

Let me put the problem a little differently and a little more
emotionally:  REXX as it stands today cannot be used to build
commercial-quality applications unless you are willing to put up
with some pretty crummy code (e.g., hard-coding array names into
subroutines).  That's a shame because I think REXX has the
potential to become the application development language of
choice, preferable even to C for most applications.  But it "ain't
gonna happen" without some serious changes to the language.

< But a solution exists.  This is to add the EXPOSE clause,
< currently limited to procedures, as a new statement:
<      EXPOSE <stuff>
< where stuff would be a list of variables AND asterisk
< representing everything.

I hate to overstate, but here it goes:  EXPOSE is grotesque.  One
of the key reasons for my suggested changes was to be able to do
away with the need to use this facility.  The idea that I should
hard code in the name of global variables to my subroutine is,
from a structured programming perspective, obscene.  It gets
programmers into very bad habits and it severely limits the power
of the language.  Now I understand that you are suggesting an
extension to EXPOSE that would allow for dynamic EXPOSEs, but
frankly I think that amounts to patching up something that is just
wrong to begin with (a little like putting smooth edges on an ugly
pipe sticking out the side of a house...I'd rather just cut off
the pipe).  An EXPOSE statement or function inside the procedure
is also too wordy.  Passing a reference is succinct.  My own vote
is to take Occam's razor to EXPOSE and do away with it.  It is
just about the only design in REXX that I think was poor
(everything else is almost too good to believe!).

Steve Bacher Responds:
< Actually, "interpret" solves all the problems mentioned.

INTERPRET can't do a call by reference for any REXX variable
inside of a subroutine.  But, beyond this, the REXX language just
does not have a mechanism currently to support a call by reference
to a STEM.  And what about my examples that actually made calls by
reference to an arbitrary node in a stem?  You just can't do any
of this with INTERPRET.

The other issue is that INTERPRET makes for *ugly* code.  Before
it became illegal under SAA to use INTERPRET before the EXPOSE
statement I had a friend who actually built a general-purpose sort
routine that took as its argument a string that contained a STEM
to EXPOSE.  Every line of the sort involved using an INTERPRET on
the variable that contained this string, and it was the most
unreadable piece of code I have ever seen.  INTERPRET has
legitimate uses.  Making up for a lack of call by reference is not
one of them.

< The return value could be captured as the variable "result".  If
< you want to retain the syntax of function calling, you need to
< have a specialized function for this.

And how do I return a structure from a function invocation except
by changing the language?  My suggestion was to allow calls like:

    *ReturnedStem. = test()
    ...
    test:procedure
    ...
    return &SomeStemIWantToReturn.

Regarding specialized functions:  how do I pass a stem by
reference and point to an arbitrary location in that stem when I
make a function call?  I just don't see how adding any number of
functions to the language is going to make up for an issue that
has to do with its basic syntax and semantics.

So, I think there are a few issues that need to be worked
out here, but I'm more convinced now than ever that REXX needs a
call by reference that supports both STEMS and portions of STEMS.
A facility to have a subroutine return a STEM and some sort of
function pointer capability (again, pointer does NOT mean a
machine address in this context!) would both be nice, but neither
is essential.  To contrast, call by reference is essential if REXX
is ever going to join the big leagues with C.

Thanks,
Will
 

Will@cup.portal.com (Will E Estes) (02/03/90)

In my last posting I say:
< I dare anyone to write in REXX a general purpose binary sort
< routine that acts on *any* REXX array.  Without some changes to
< the *language* it can't be done, and I think that should cause
< some serious concern to anyone who wants to use REXX as more
< than a shell language.

I should clarify this "dare", because I just had a nightmare
vision about the kind of code that someone is going to send flying
at us over the net because of assumptions I leave out of my
original statement:

(1) I dare anyone to write in REXX a general purpose binary sort
routine that acts on *any* REXX array and uses the PROCEDURE
keyword on the subroutine.

(2) I dare anyone to write in REXX a general purpose binary sort
routine that acts on *any* REXX array without the PROCEDURE
keyword on the subroutine that doesn't look uglier than Bill the
Cat when he wakes up in the morning.

The routine for (1) can't be written.  And of course using the
PROCEDURE keyword is a must for anyone who wants to write
structured code.

If you don't use the PROCEDURE keyword at all, then you can use
INTERPRET liberally throughout the subroutine to do just about
anything.  But this is a totally unacceptable solution for any
number of reasons: 1) the code looks like hell; 2) it is not
efficient; 3) it is not supported in the compiler; 4) it requires
you to not use the PROCEDURE keyword which exposes all of the
caller's environment, and this is hack programming at its worst.

Enough said,
Will              (sun!portal!cup.portal.com!Will)
 

wagner@pucc.Princeton.EDU (John Wagner) (02/06/90)

In article <26534@cup.portal.com>, Will@cup.portal.com (Will E Estes) writes:

> (1) I dare anyone to write in REXX a general purpose binary sort
> routine that acts on *any* REXX array and uses the PROCEDURE
> keyword on the subroutine.
> 
> (2) I dare anyone to write in REXX a general purpose binary sort
> routine that acts on *any* REXX array without the PROCEDURE
> keyword on the subroutine that doesn't look uglier than Bill the
> Cat when he wakes up in the morning.
> 
> The routine for (1) can't be written.  And of course using the
> PROCEDURE keyword is a must for anyone who wants to write
> structured code.

Will, This is simply not true.  You may not like how the code looks, but
that is different than saying it cannot be done.  Remember that the
SAA restriction on using "INTERPRET 'name: procedure expose' var"
is an IBM restriction that is not part of the language.  Don't use
the IBM manuals for REXX when you are trying to understand what
the language is supposed to be.  The only source for that information
is Colishaw's book "The REXX Language, A Practical Approach to 
Programming". 

> If you don't use the PROCEDURE keyword at all, then you can use
> INTERPRET liberally throughout the subroutine to do just about
> anything.  But this is a totally unacceptable solution for any
> number of reasons: 1) the code looks like hell; 2) it is not
> efficient; 3) it is not supported in the compiler; 4) it requires
> you to not use the PROCEDURE keyword which exposes all of the
> caller's environment, and this is hack programming at its worst.

I don't know what environment you are using REXX in, but I
would guess that it is not VM/CMS since you seem to be missing the
"feel" of it.  This comes through in the way you state your dare.
You have assumed that the correct answer is the ability to write
all code in REXX.  Colishaw never meant for that to be the case.
REXX is a blend of high level code with system dependent function
packages.  You cannot separate the two.

The appropriate response to your dare is that two forms come to mind.
The first is:

    call sort 'Stem_to_sort.' , 'Stem.' < , 'Ascending' >
                                        < , 'Descending' > 

This places the sorted values found in 'Stem_to_sort.' into the stem
'Stem.' with 'Stem.0' containing the number of values.  The third 
parameter just specifies the sort order.  It uses the standard REXX
technique of only making the first character significant so you could
code 'DownDamnIt' it you wanted.  The default would be ascending.

This procedure would sort any value starting with 'Stem_to_sort.' so
you might want to add another parameter to specify valid tail types
(Any, Numeric, Character, etc.).  It could also be used to sort some
portion of a stem's values by specifying a partial tail, as in

     call sort 'Unsorted.Array.' , 'Sorted.array.' , 'D'

If what you want to do is sort words in a string you use

     SortedString = sortwords(string <, 'Ascending' >  )
                                     <, 'Descending' > )

This one can be done using a REXX procedure, but is quicker in machine
code.
    
Function packages are meant to do exactly what their name implies, provide
function not found in the base REXX language.  They are meant as the way
to make REXX extensible.

You might want to take a look at a REXX function package available from
Berthold Pasch (BITNET:  PASCH@DHDIBM1  VNET: PASCH at GYSVMHD1).  The
package is known as XVAR (eXtended VARiable support) and is for REXX
programs in CMS.  It allows you to access copies of the variables in a
callers routine (both R/O and R/W).  Using this package it is possible

Will@cup.portal.com (Will E Estes) (02/08/90)

Thanks for the feedback.  You touch on several different points,
and I'll try to cover each of them.  I am re-arranging the order
of your points.

< Remember that the SAA restriction on using "INTERPRET 'name:
< procedure expose' var" is an IBM restriction that is not part of
< the language.  Don't use the IBM manuals for REXX when you are
< trying to understand what the language is supposed to be.  The
< only source for that information is Colishaw's book "The REXX
< Language, A Practical Approach to Programming".

This is fine if you use Amiga REXX.  However, for the rest of us
who live in the IBM world, your statement is wrong.

Legally, since Mike was working for IBM on an IBM product when he
wrote REXX, IBM, and not Mike, controls the language definition.

Practically speaking, in 1993, when I and 20 million other people
are using IBM REXX under OS/2, VM/CMS, and MVS, we will be using a
version of the language that does not allow you to use the
INTERPRET keyword before the PROCEDURE keyword in a subroutine.
In fact, IBM is still modifying the language definition, and as
far as I'm concerned SAA REXX is REXX.

Finally, Cowlishaw's book just came out in 1990 with a second
edition.  I would be willing to bet good money that Mike's book
now conforms to SAA REXX and not to his own original definition.

< Will, This is simply not true.  You may not like how the code
< looks, but that is different than saying it cannot be done.

I think you are misunderstanding what I said.  I said:

(1) you can't write the routine *IN THE REXX LANGUAGE* *WITH THE
PROCEDURE* keyword in place.

By REXX *I* mean SAA REXX.  You can't write this routine in SAA
REXX.  And to appeal to Cowlishaw's original definition is to
really squirrel the issue.  But if you insist on hanging onto this
thread, then I suppose I can just change the claim below in (2) to
not reference the PROCEDURE keyword.

Try to see the big picture here.  I'm not trying to challenge your
ability to write code.  I can write the routines you refer to, as
can you.  My point is that REXX can't do call by reference (or
anything that approximates it), and it suffers as a language
because of that.

I also said:

(2) you can't write the routine IN THE REXX LANGUAGE WITHOUT THE
PROCEDURE keyword unless you are willing to put up with very ugly
code.

This is not, by my reading, an assertion that the routine cannot
be written.  Rather, it is an assertion that the code *can* be
written and it will look like hell.  And it does.  Moreover, the
resulting code is inefficient, not compilable, and it is bad
technique from a structured programming perspective.

I think it is fair that we be able to debate each of those
assertions if you like, but please do not hold me to saying that
the claim I make in (2) above is that a routine cannot be written.
That is not what it says.

< I don't know what environment you are using REXX in, but I
< would guess that it is not VM/CMS since you seem to be missing
< the "feel" of it.  This comes through in the way you state your
< dare.  You have assumed that the correct answer is the ability
< to write all code in REXX.  Colishaw never meant for that to be
< the case.  REXX is a blend of high level code with system
< dependent function packages.  You cannot separate the two.

Well, I didn't assume that the best way to write a sort routine
for REXX is to write it in REXX; rather, I used the sort as an
arbitrary example of how REXX cannot do call by reference.

Nevertheless, your concern is valid.  I'm well aware about
function packages, and by now SAS' C compiler has so many
excellent REXX hooks that you could probably even use that.  My
objective in posting my note, however, was to rhetorically ask if
the REXX language itself couldn't be improved through an ability
to do call by reference.  I am convinced it can be.

PRACTICALLY speaking, when I was doing VM/CMS consulting few of my
clients had a C compiler, and when you have two weeks to write
thousands of lines of REXX you really don't want to hassle writing
assembler code unless you know it inside and out.  My last client
not only forbid me from writing assembler, but he didn't even
allow me to upload routines from Bitnet because of a fear about
viruses.  It's very easy for us to sit in glass houses and anytime
we don't find something in REXX just flippantly say that we could
always code it in assembler.  In the real world, however, only a
few of us get such opportunities.  REXX is a great prototyping
language, and you defeat that purpose in the language if you
insist that we resort to assembly code every time we run into a
call by reference problem.

< Function packages are meant to do exactly what their name
< implies, provide function not found in the base REXX
< language.  They are meant as the way to make REXX extensible.

To my way of thinking there are two good reasons to write a
function package:  1) you need to make something more efficient;
and 2) you need to do something that is very OS-dependent that is
just not reasonable to do in REXX.  The excellent IUCV routines
from University of Maine are an example of the latter.  It is
disappointing, though, when we have to rely on function packages
to make up for deficiencies that are rooted in the syntax and semantics of 
the language itself.  Writing a routine in assembler because I
can't do call by reference in REXX should not be accepted as "the
REXX way of doing things."  It should be taken as evidence that
maybe REXX by itself does not do enough and could do better.
To say that this is not the way Mike wanted us to do things is to
my way of thinking simply Argument Ad Hominem.  Since Mike isn't
here to give us his reasoning himself, I don't see why we can't go
through the reasoning behind his design decisions ourselves.
Heck, this board is supposed to contribute to our understanding of
the language, isn't it?  

Let me be very clear that I am crazy about REXX.  It is one of the
most elegant languages I have ever used.  It's one of the better
technologies to come out of IBM, in my opinion.  I just think it
could be better.  I can be convinced that I'm wrong, though.

< The appropriate response to your dare is that two forms come to
< mind. The first is:
<
<    call sort 'Stem_to_sort.' , 'Stem.' < , 'Ascending' >
<                                        < , 'Descending' >
<

If by this you are referring to an assembler routine, I think I
covered that already.  If by this you are referring to a REXX
routine, then pretty much falls under the spectre of (2) above,
doesn't it?  It uses INTERPRET liberally throughout, and it falls
victim to the four problems I posted in my original note.  So I
don't see this routine as a disclaimer of anything that I said
originally.  You are right that the routine can be written if one
does not use the PROCEDURE keyword and if one uses INTERPRET.  But
I think it is proof of my point and not a response to it.  And the
issue over whether we are talking SAA REXX or Mike's original REXX
is not really very important relative the concern I'm trying to
raise.

< You might want to take a look at a REXX function package
< available from Berthold Pasch (BITNET:  PASCH@DHDIBM1 VNET:
< PASCH at GYSVMHD1).  The package is known as XVAR (eXtended
< VARiable support) and is for REXX programs in CMS.  It allows
< you to access copies of the variables in a callers routine (both
< R/O and R/W).

Sounds good.  Thanks for the info.

Will              (sun!portal!cup.portal.com!Will)

wagner@pucc.Princeton.EDU (John Wagner) (02/09/90)

Will, A piece of information  you may not know:

In the pre-VM/SP version of REXX (the IBM internal use only version also
available to some groups doing joint research with IBM) included an interface that could have been used to create call by value and call by reference.  It was a piece of the EXECCOMM interface that was removed
by development when the product was released.

You can still do call by value using the VALUE() function.  Call by
reference would require a handle that it is no longer possible to create
in SAA without modifying the interpreter.  Since the interpreter is now
entirely without source code (and disassembly is explicityly disallowed
by the license agreement signed by the site) it is unlikely that an user
site will make the effort to implement what you are looking for even if
they think it is a good idea.

This leaves you with the option of convincing IBM to do it, convincing
some third party vendor with an existing implementation to do it, or
writing your own interpreter.  While the last option might be fun, unless
someone is really willing to push it in the IBM world, it is likely to fail
irrespective of the quality of the product.

I keep wondering why you aren't looking at PL/I.  Your goal (given that
INTERPRET is not to be used) is effectively making REXX into PL/I.
Or as an alternative, libraries of REXX functions that are included 
into the code by a macro processor style operation (some companies have
developed procedures in this direction).

hayes@ultra.com (John Hayes) (02/10/90)

This entire discussion seems to have been conducted under the assumption that
REXX is a programming language.  As I learned it, while it may technically
be called a language, it's primary design function was to provide a better
way to write simple interpreted scripts than exec2 (An older interpreted
language available on VM/CMS systems for those in the Amiga world...).
These scripts were generally installation scripts or otherwise small scripts
to be executed only occasionally, not to become a major programming language. 

REXX scripts (or programs as some people prefer to call them) are very easy to
write, thus making it the perfect language for prototyping parts of larger
software projects.  Initially, REXX was only available as an interpreter.
The ease of programming in it has led to the development of the REXX compiler.
Upon the initial design of REXX, it was never supposed to be anything but an 
interpreted language.  A similar parallel can be drawn to (gasp!) the BASIC 
programming language.  

BASIC was for many of the recent generation, a quick and easy way to learn a
lot of bad programming habits.  Most of the computers (espicially micro 
computers) ran a version of interpreted basic (microsoft basic became a defacto
standard).  As the popularity of BASIC grew (and microcomputer became more
powerful) a compiler BASIC evolved into what is now commonly called Business 
BASIC.  And now we have a generation of 'programmers' who know Business BASIC
and call themselves software engineers.

As I see it, using REXX as anything but a quick prototyping language and
for macro definition under XEDIT, we are just bound to waste more cpu cycles
by not having those applications written in a true, optimizable language.



-- 
John Wm. Hayes  hayes@ultra.com  UltraNetwork Technologies  (408)922-0100 x204 

peter@ficc.uu.net (Peter da Silva) (02/20/90)

In article <1990Feb9.181153.417@ultra.com> hayes@ultra.com (John Hayes) writes:
> As I see it, using REXX as anything but a quick prototyping language and
> for macro definition under XEDIT, we are just bound to waste more cpu cycles
> by not having those applications written in a true, optimizable language.

While I agree with the categorisation of REXX as a kindler and gentler BASIC,
I don't see that this conclusion holds. Even on large IBM systems CPU cycles
are cheaper than programmer cycles, and if it's easier to program in REXX than
PL/I why not use it? Consider, for example, the UNIX environment where so much
of the system is actually built up out of shell scripts. Consider C news, which
uses shell scripts extensively but by virtue of intelligent encapsulation gets
something like 20 times the performance of B news where it counts.

On the other hand, I'm not sure that a compiled REXX is a good idea, given the
ease of adding external commands in either environment. Write your tight inner
loops in PL/I and glue them together with easy-to-read, modular, REXX.
-- 
 _--_|\  Peter da Silva. +1 713 274 5180. <peter@ficc.uu.net>.
/      \
\_.--._/ Xenix Support -- it's not just a job, it's an adventure!
      v  "Have you hugged your wolf today?" `-_-'

Will@cup.portal.com (Will E Estes) (02/21/90)

< This entire discussion seems to have been conducted under the assumption that
< REXX is a programming language.  As I learned it, while it may technically
< be called a language, it's primary design function was to provide a better
< way to write simple interpreted scripts than exec2 (An older interpreted

Right you are.  But the implementation far exceeds this initial purpose.
Cowlishaw was asked to build a better Volkswagon and he came up with
something that looks a little more like a Porsche.  It's a question of
objectively looking at a product and what it does and how it does it
and coming to our own conclusions rather that blindly accepting IBM's
pronouncements.  

< As I see it, using REXX as anything but a quick prototyping language and
< for macro definition under XEDIT, we are just bound to waste more cpu cycles
< by not having those applications written in a true, optimizable language.

First, there are ways to optimize typeless languages so that they would perform
quite reasonably in compiled form.   Second, even if we accept the premise
that REXX is only valuable as an interpretive prototyping language, it
is still valid to ask what changes could we make to the language to make
it more powerful for just that purpose.  A prototyping language is a programmin
g
language none the less, and there are questions of ease of use, maintainability
of code, etc.  Third, you have not spent much time in the real world if you
really believe that REXX is being used as a prototyping language.  On VM/CMS
it is used by many companies as a mainstream application development tool.
I know of one site that has a REXX system that approaches one million lines
of code.  I know of many sites with 10,000+ line applications.  To argue
that this is not an appropriate use of the language is like arguing that
people shouldn't drive in the rain because it's dangerous.  People are
going to drive in the rain anyway because practical concerns make it 
impossible not to, so car manufacturers improve the basic design of their
cars for rainy conditions.  Similarly, companies in the real world are
using REXX for production applications because of practical concerns (like
it's nearly impossible to find qualified C and assembly programmers and it's
much harder to maintain the resulting code), so why not accomodate reality
by improving REXX?

Will              (sun!portal!cup.portal.com!Will)  

tron1@tronsbox.UUCP (HIM) (02/22/90)

>In article <1990Feb9.181153.417@ultra.com> hayes@ultra.com (John Hayes)
>writes:
>> As I see it, using REXX as anything but a quick prototyping language and
>> for macro definition under XEDIT, we are just bound to waste more cpu cycles
>> by not having those applications written in a true, optimizable language.

POSSIBLY in those situations where REXX is >JUST< a glamorous way to write
batch style scripts that would be true.   

BUT , REXX (specifically AMIGA REXX) is so much more. In AREXX , 90% of the
work in a program is done through messages to C or whatever compiled user
programs.

Consider the case where on my Amiga , I would write a REXX script that will
take the output of uutraf (a UUCP profiler) that comes over a terminal
program , and DYNAMICALLY build a graph of that data in a graphics packadge
(the wonder of Multi-Tasking) by the process of ..

1) Parsing the incomming data from a message port attached to the terminal 
   program...

2) Sending messages like "DRAW LINE 100,100 200,200" to my paint program.


This is >SO< simple and >SO< usefull as an interpreted language (or a
compiler for all I care .. but REXX rather than >C<) that the wasted CPU
cycles are not a problem.

(FYI - the overhead in data structure initializion for IPC on AMiga is such
that I wouldnt want to do it for something this simple when the resident
REXX module already does it.)


>interpreted language.  A similar parallel can be drawn to (gasp!) the BASIC 
>programming language.  

Wich in it's modern form is a Compiled, structured, completely useful
language. (A bit wordy).  Languages evolve.

>BASIC was for many of the recent generation, a quick and easy way to learn a
>lot of bad programming habits.  Most of the computers (espicially micro 

But no longer.

Basic has done more during its evolution than many suspect , and REXX does
the same thing (on the Amiga) for MULTI-PROCESSING. The ability for AREXX to
control multiple INDEPENDANT applications is staggering.


Come to think of it , there had better be a UNIX implementation of >A<REXX
soon!

****************************************************************************
Everything I say is Copr.  1990, except the stuff I stole from someone else
and the stuff I don't want responsibility for.
 
Kenneth J. Jamieson: Xanadu Enterprises Inc. "Professional Amiga Software"
      UUCP: tron1@tronsbox.UUCP  BEST PATH ---> uunet!tronsbox!tron1 
      Sysop, Romantic Encounters BBS - (201)759-8450 / (201)759-8568 
****************************************************************************