🚀 go-pugleaf

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