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

[Fergus Henderson]

On 28-Dec-2001, Mark Phillips <mark@austrics.com.au> wrote:
> 
> 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.
>
> Perhaps functional/logic languages need to move further in the
> imperative direction???

I had a brief glance at this paper.  This paper is about a completely
different issue than I/O.  The "OO" approach that they talk about here
could be done in Haskell, Clean, or Mercury using type classes, I believe.

This paper is not about functional versus imperative.
It is about discriminated unions (algebraic data types)
versus hierarchical decomposition via class hierarchies.
But since modern functional languages have both of these,
I don't think there is anything in the paper that couldn't
be applied in modern functional languages too.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.