Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!portal!cup.portal.com!Will
From: Will@cup.portal.com (Will E Estes)
Newsgroups: comp.lang.rexx
Subject: A Suggestion For Adding Function Pointers To REXX
Message-ID: <25545@cup.portal.com>
Date: 2 Jan 90 03:22:54 GMT
Organization: The Portal System (TM)
Lines: 105

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)