Re: [stack] Joy's relationship to FP + a Joy variant with combining forms

----- Original Message ----- 
From: "John Nowak" <[email protected]>
To: <[email protected]>
Sent: Saturday, May 31, 2008 11:58 AM
Subject: Re: [stack] Joy's relationship to FP + a Joy variant with combining forms


> 
> On May 31, 2008, at 1:31 PM, Stevan Apter wrote:
> 
>> my memory is that backus specifically
>> credits iverson's work and APL as the inspiration for FP's combining
>> forms in his original paper, although i could be mistaken.
> 
> Indeed he did:
> 
> "We owe a great debt to Kenneth Iverson for showing us that there are  
> programs that are neither word-at-a-time nor dependent on lambda  
> expressions, and for introducing us to the use of new functional  
> forms." - John Backus, 'Can Programming Be Liberated from the von  
> Neumann Style?'
> 
>> in later generation APLs, it was possible to define operators as  
>> second-
>> order functions in the same way that one could define first-order  
>> functions.
> 
> I believe this is equivalent to what I'm suggesting. In other words,  
> you can make new second order operators, but there is still no way to  
> represent functions as objects (i.e. no first class functions).

right.

> 
> What I'm desperately curious about is why certain languages like FP,  
> APL, J, etc, avoid first class functions. Obviously there are  
> advantages to only having first order functions, and I see a few ways  
> this is useful (termination proofs are much easier, etc), but I'm  
> admittedly less informed on this subject than I'd like to be. If  
> anyone would be willing to point me in the direction of something that  
> discusses the advantages of the FP/APJ/J approach in contrast to the  
> ML/Haskell approach, I'd be very grateful. Unfortunately, most papers  
> on FP seem to be locked away on sites I don't have access to, which is  
> doubly bad as there are so few to begin with.

i don't recall any specific discussions.  based on conversations with 
APL implementation teams over the years, i'm guessing that they never
saw the point of having first-class functions, much less first-class
operators.  (K is the exception here - everything is first-class.)

classical APL operators like / take functions of fixed and well-known
arity:  +/, but not first/.  moreover, functions of any kind have zero,
one, or two arguments, and operators have one or two arguments.  the
reasons, i gather, are partly syntactic, partly semantic.  (in APL it's
often difficult to disentangle these concerns.)

i think you can trace these ideas (and limitations) to two sources:
(i) early APL implementations had to be squeezed into tiny memory, and
(ii) the implementors were mathematicians, and the generating ideas
behind APL were based on iverson's program for the reform and regimentation
of mathematical notation (see his book "A Programming Language".)  APL
represented a series of compromises dictated by the existing technology
and the uses envisioned by the implementors.

to get a good feel for how people were thinking about these things, you
might want to get hold of an early edition of gilman & rose's "APL: an
interactive approach."  this is an introductory textbook, but i think
this makes it easy to see what was *not* on the horizon at that time.
in particular, the fundamental (ontological?) distinction between *data*
(which varies) and *functions* (which did not.)  i recall one of these
early implementors -- i think it might have been jim brown of ibm --
remarking that defined operators might not be too useful, since the
handful of primitive operators seemed to cover all the useful cases.
and no one could think of any useful examples of third- or fourth-order
functions.

i think it would be fairly easy to gin up a model of concatenative APL,
with or without array primitives (but definitely without the symbolic
character set!) 

fixed forms instead of HOFs is an interesting idea.  as always with me,
the question is what loss of expressiveness (if any) will result.

> 
> - John
>