Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!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: <26534@cup.portal.com>
Date: 2 Feb 90 21:47:09 GMT
References: <25545@cup.portal.com> <5344.25b20330@elroy.uh.edu>
  <25c5436f:31.2comp.lang.rexx;1@tronsbox.UUCP> <26498@cup.portal.com>
Organization: The Portal System (TM)
Lines: 36

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)