gjohnson@cornell.UUCP (05/09/84)
I noticed in John Backus's Functional Programming paper (August 1978 CACM, p. 613) that FP has an iteration mechanism. He levels the criticism at APL (and I think he is right) that it contains two parts, one of which is lovely and one of which is ugly. The pretty part is the set of array manipulation functions and operators, and the ugly part is the statement-level control flow mechanism. Basically, there is what one does inside of expressions (one-liners if you will), and what one does to manipulate which expression gets executed next in a user-defined function. The claim for FP, if I understand it correctly, is that it has the beauty of the expression-oriented part of APL but it does not have the ugly statement-level control flow. The expression part of the language has been augmented in such a way as to render unnecessary the statement-level control flow. (Statement-level state manipulation, like states in general, has withered away, as it were.) In APL one can use bit vectors and the reduction operator ("/") to achieve conditional behavior (one might call this the expression-language cognate of an "if" statement), but there is no really general expression-level cognate of repetitive execution in APL. So the question is, can we add some sort of general repetitive execution operator to the expression sub-language of APL? If we had arrays of functions, we might be able to generalize the reduction operator. (I'm not sure this really flies, but here goes..) The array of 1's and 0' on the left-hand side of the reduction operator says "do something 1 time" or "do something 0 times." Perhaps we should allow numeric values other than 0 and 1 to appear in the vector on the left of the reduction operator. The problem with this is that we must decide a priori how many times we want something to be done, and there are many situations (precisely those which force us against our will to write APL functions with loops in them) in which the decision of whether to perform iteration N+1 or terminate the loop depends on the result of the computation performed during iteration N. So, how about allowing a vector of functions to appear on the left of the reduction operator? Then, the decision of whether or not to iterate could be made when we need it, i.e. when iteration N has been completed. I guess I see about a million problems with this technique, but I will offer it up to provoke thought on the subject of cleanly incorporating a reasonable notion of iteration into the expression part of APL. By the way, I don't think that the ability to write recursive functions in APL counts; I would claim that that technique falls into the "statment-level" sub-language. - Greg Johnson gjohnson@cornell
gnu@sun.uucp (John Gilmore) (05/16/84)
Several APL systems have extensions like what you propose. Systems from IBM, STSC, and IPSA all include an extension to compression called "replicate"; each left argument element says how many copies of the right argument element should appear in the result. Also, for multiple application of functions, the "power" operator is used. I don't recall exactly how it works for dyadics, but it's easy for monadics. It just applies the function N times where N and the function are the arguments to the operator. There are degenerate cases where N is missing (apply the function until the result stops changing, as in calculus) or where N is -1 (give the inverse function). I'd suggest getting a copy of the IBM APL2 Language Manual to get some idea of what is going on in the modern APL world. You might also check some of the "nested arrays and operators" papers from the last 5 or 6 APL conferences.
watapl@watmath.UUCP (APL Standards) (05/17/84)
Here is my understanding of how "replicate" works: 0 1 0 1 1 0 / 1 2 3 4 5 6 2 4 5 0 2 0 3 4 0 / 7 8 9 10 11 12 8 8 10 10 10 11 11 11 11