Leaving the Nest

Transcribed from the printed issue; not yet reviewed. Read it in the PDF of the issue, page 13

Recently I have been working with a couple of very avant garde organizations that seem to use nested arrays because they are possible. I should like to enter an alternative view, based on experience with using APL since the day after Al Rose and Larry Breed had the first prototype up and running on an IBM mainframe.

My specific beef has to do with passing arguments to, and results from, functions. It has long been my practice that any function a user sees is nihiladic — no arguments and no explicit results. Many subroutines, invisible to the user, do require arguments: lists of products, column headings, row headings, index to the Help file, various kinds of data (which may range from scalars to arrays of rank 3 or 4).

These other organizations, staffed by people much younger than me and therefore more amenable to modern procedures, seem to prefer to build elaborate nested arrays with all the arguments, and to generate results as nested arrays which don’t have the shape you think they have when you look at them.

I see no point in specifying the index to the Help file — it is always 1↑tt where tt is a global variable with lots of ⎕AI kinds of information, including a pointer to where this particular function (main program or subroutine) is stored in the file of programs. Row headings and column headings are easy to construct (or were before they got rid of ⎕EDIT) as a character array of some suitable shape which is stored in a file of program constants.

My workspace has only 16MB, so I differ from the Supreme Satan at Microsoft in my willingness to clutter up the workspace with functions and variables that won’t be used for a couple of hours. Call what you need from file when you need it, and get rid of it afterwards. Conserve the workspace for data that will do the user some good in running his business. This attitude may have been inculcated when my workspace was a punched card with 80 columns, later going up to a 1401 which had a whopping 3K of space.

When a subroutine is closely coupled with its main program I see no harm in using a global variable for data. I think it may still be true that if I don’t modify the data no second copy is made to fill up the workspace. If data are passed as an argument there is a greater danger of WSFULL.

It seems to me that a subroutine using nested arrays requires considerable work before it is called to assemble each of the eggs in the nest with precisely the right punctuation, like an old-fashioned FORTRAN program. Then the first thing the subroutine does is to disassemble the nesting to get back to the elements which were available to build the nest in the first place. Somehow that does not appeal to my sense of fitness.

I find that complicated nested arrays are hard to hold in my head, hard to write routines to build them, probably time-consuming in execution. Therefore I suggest that the profession might give some careful consideration to passing a vector of numbers which the program can interpret to go get what it wants out of files. It certainly makes maintenance of the contents of those arrays much easier. With some of my handy-dandy development tools editing stuff in files becomes self-documenting which helps other people to follow what has gone on.