low-level approach

[Francois-Rene Rideau]

I appreciate what Billy Tanksley writes about the benefits of using
combinators and eliciting variables so as to make dataflow explicit,
and how it can be a great tool when designing algorithms.

As for combinator languages in academia, let me just remind our readers
that combinators were very much studied ever since the beginning of CS.
The SKI combinators were already used by Schoefinkel in the 1920's,
before the lambda-calculus was even born. Haskell Curry studied them a lot
- see Curry and Feys' "Combinatory Logic", volume 1 published in 1958
(btw, "combinatory logic" is about *computation* with combinators,
although Curry was also after a way to do reasoning without variables:
"illative combinatory logic"). Combinators are very much studied by in
computer science theory, by functional language designers and implementers,
semanticians, logicists, graph theorists. They are often the basis of the
programming models used as targets by compilers for functional languages:
There are lots of papers about graph-reduction models with combinators
for pure functional languages (Haskell, Clean), and the whole idea behind
CAML was to compile functional programs to some special kind of a stack
machine implementing categorical combinators. 

In conclusion, combinators are a very useful conceptual tool, that are
both studied by scientists, and put to good use by implementers.
However, there is a good reason why they are not so much exposed to the
public at the outer layers of programming languages, but only used
in the lower-levels of compilers: they are very low-level, in their own way.
Programming *only* with combinators can be very tedious and obfuscating
- witness unlambda (based on SKI combinators), or finitary lambda calculi.
Combinators certainly DO help express and handle data-flow constraints,
and when optimizing them is what is meant, they are a great paradigm.
But when these constraints do not matter, or when you want the system
to handle them for you (and YES, there are cases when you do), then
expliciting them gets in the way, and so do combinators.

Ideally, you'd have a system that would allow you to dynamically change
your point of view on the same program; this is what refactoring is about,
although refactoring is often used in as destructive rather than as
explorative. I'm sure combinators are studied a lot by people doing
refactoring for functional programming languages (has anyone contacted
Claus Reinke about that?).

[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ]
[  TUNES project for a Free Reflective Computing System  | http://tunes.org  ]
"The society which scorns excellence in plumbing as a humble activity
and tolerates shoddiness in philosophy because it is an exaulted
activity will have neither good plumbing nor good philosophy.
Neither its pipes nor its theories will hold water."