Path: utzoo!attcan!uunet!snorkelwacker!apple!portal!portal!cup.portal.com!Will
From: Will@cup.portal.com (Will E Estes)
Newsgroups: comp.lang.rexx
Subject: Re: A Suggestion For Adding Function Pointers To REXX
Message-ID: <26705@cup.portal.com>
Date: 8 Feb 90 04:32:15 GMT
References: <26534@cup.portal.com> <25545@cup.portal.com>
  <5344.25b20330@elroy.uh.edu> <13623@phoenix.Princeton.EDU>
Organization: The Portal System (TM)
Lines: 155

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)