Re: [stack] language hierarchy

>> And using the
>> already existing recursive methods is more in line with concatenative
>> theory anyway, ..., so I'll forget about it ;-)
> 
> Is that true? Are the *rec functions especially good with
> concatenative languages? (I don't know.) I'm sure they work with any
> functional language...

i've wondered about this for years.  at first glance, it seems like
eliminating recursion in favor of *rec combinators would be as fruitful
as eliminating iteration in APL, J, K.  

my last project involved some extremely hairy recursive processing
on complex, inter-related tree-like structures.  over an interval
of several years, i became quite fluent in deploying a handful of
techniques for operating on these structures, and it occurred to me
more than once to try to map these patterns to manfred's joy
recursion abstractions.  but i never did succeed in that effort.

while recursion seems simple enough if you concentrate on the 
standard handful of examples (fibonacci, factorial, &c.), things
get complicated real fast.  perhaps more to the point, the problem-
set for which recursion is a natural technique seems to thin out
rather quickly.

APLers may be familiar with a parallel phenomenon.  you've got 
about 20 or 30 first-order primitives in most languages:  plus, minus,
times, &c., count, reverse, rotate, &c., and a few others.  out of
those, you construct lots of programs (also first order:  applied to
data, they return data.)  and then you've got (at least in the APLs)
a handful of second-order primitives:  reduce, scan, &c.  and those
are useful because they abstract from common iteration patterns.  so
back in the 80s, the APL2 folks at IBM implemented the machinery
for "defined operators".  the programmer could now define programs
("functions") which took first order functions as arguments ("operands")
and return first order functions.  so now you could write reduce, scan,
&c.  the problem was, no one could really find problems which lent
themselves naturally to defined operators.  in theory, these were 
quite powerful, but practically, they just didn't mesh with the
problems people were actually trying to solve.

i recall a conversation with some of the APL guys at one of the 
minnowbrook conferences in which i asked if anyone had ever found a
use for a third-order function.  of course, it was possible to add
the machinery for defined functions of any order, but could anyone
think of a use for this?  

> 
>> Don
> 
> -Wm
>