[clean-list] Clean's answer to the Functional Achilles-heel

[Adrian Hey]

On Friday 28 December 2001  8:15 am, Mark Phillips wrote:
> Fergus Henderson wrote:
> > It's true that no single approach has emerged to be _the_ answer,
> > but calling it "the Achilles-heel" is way too strong.
> > All of the different approaches are certainly adequate.
>
> Probably you are right in saying that "Achilles-heel" is too strong.

Yes, I think so too. IMHO the current I schemes used in the two
functional languages I've used in any serious way (Clean and Haskell)
are in no way inferior to those used in imperative languages (object
oriented or otherwise). In fact they are superior in one important
respect, in that IO performing actions are first class and can be
treated as abstract data types.

But, as was discussed at some length on this list (world as value
thread) I personally don't agree that they are adequate
wrt concurrency. But that's also true of every other language
I've used. The only functional languages I'm aware of that
seriously address the issue are Erlang,Pict and O'Haskell (but
I have no real experience with any of these so can't really say
whether the solutions work well.) 

> I wonder however whether the Functional/Logic approach is only half
> the answer to a good programming paradigm.

I would agree with that assessment, though I'm not sure if it's for
the same reason. As far as describing functional relationships between
values is concerned ('pure' computation in effect), I don't think
object orientation really has any advantages over purely functional
approach.

As for the IO problems (concurrency, mutable state etc..) I think
object orientation is a good paradigm, but that's all. IMHO the
reason OO gets so much undeserved hype is that all popular OO languages
come from the imperative tradition (everything is IO in effect, there's
no concept of referentially transparent 'pure' computation.)

Have you looked at O'Haskell?

>  Haskell's approach to IO,
> if I understand things correctly, is to embed its functional language
> inside a specialized form of imperative engine.

I think a good way to think of it is like this..

A Haskell program is an expression (constructed using pure functions)
which evaluates to an imperative program in an abstract language
(which you could call iomonad) which is then executed to cause the
program to have some observable effect on the outside world. The
claims for pure functionality are only valid in so far as the
language used to construct the iomonad program (Haskell) is purely
functional. But the iomonad program itself is not purely functional,
any more than a program written in C is (you could write a purely
functional program which evaluated to a C program (string) and then
compile and execute that to get observable effects). 

I'm not sure everybody would agree with this view though.

> Does the Clean approach do something similar?

Well, philosophically Clean is different in that it uses the
world as value paradigm, and the assertion is that this preserves
referential transparency (and that therefore Clean IO is purely
functional) but in practice there's no significant difference
between this and the Haskell monadic approach. You can create
an IO monad from world as value 'functions' if you like.

Where there is a big difference between concurrent Clean and
concurrent Haskell is in the treatment of concurrency (surprise:-)

Concurrent Haskell provides concurrency of the traditional
'non-deterministic' variety. Concurrent Clean splits the world
into a heirachy of notionally independent sub-worlds
(environments) which can be manipulated concurrently because
they are independent. This is said to be 'deterministic' because
actions on one environment have no influence on any other
environment. (But I'm a little sceptical about this) 

> One of functional programming's big "claims to fame" is the
> ease with which one may analyse it, ie prove things about programs.
> I wonder however whether this ease comes at a cost.  Perhaps
> imperative languages are more complicated to analyse, but
> allow some forms of (desirable) complexity that functional
> languages do not.  I've been reading a paper,
>
>   http://citeseer.nj.nec.com/krishnamurthi98synthesizing.html
>
> where the authors suggest a means of combining object-oriented
> and functional approachs, the result of which is a paradigm
> that allows for maxiumum code reuse.  The thing which struck
> me about this paper was that their implementation required
> the power of an object-oriented language --- functional languages
> do not seem to have sufficient power to express their model.

I don't seem to be able to download this paper, but I wouldn't
say that object oriented languages are inherently more powerful.
Arguably untyped or dynamically typed languages are more powerful
than statically typed languages. But there are also risks and costs
with this approach. Clean 2 now has dynamic types if you need
them (I haven't tried using them yet). Crappy type systems seem
to be a common feature of OO languages, so maybe they are more
powerful :-)

> Perhaps functional/logic languages need to move further in the
> imperative direction???  (I speak as a novice, so I could well
> be wrong --- I am trying to get a feel for the landscape of
> programming paradigms.)

No I don't think so. IMHO there's plenty of scope for
improvement in the way functional languages deal with IO
in general and concurrency in particular. But my hunch is it's
more likely that that improvement will come from research into
exotica like action calculi and pi calculus (about which I know
little I must confess) than it will from copying current
imperative languages, even of those of the OO variety.

Regards
--
Adrian Hey