world as value

[Fergus Henderson]

On 17-Jun-1999, Adrian Hey <ahey@iee.org> wrote:
> I've been wondering wether or not I dare utter this heresy in public for some
> time. Now seems an appropriate moment, so here goes..
> 
>    "Who said that languages have to be purely functional anyway."

The important property that so-called "purely functional" languages
have is not really that everything is purely functional; all the purely
functional languages do in fact provide ways for programs to do I/O,
call C, and so on.  The really important thing, IMHO, is making sure
that the distinction between purely functional parts and the parts
which might have side effects and nondeterminism is clearly delineated
and can be easily reasoned about.

It helps if the imperative parts also have a declarative semantics,
as they do in Clean, Haskell, and Mercury, but this is not essential.

> I guess nobody will admit to this, but there seems to be a general consensus
> in the Clean and Haskell communities that this is the way to go. The more I
> think about this the more I believe that the expression 'purely functional
> programming language' is self contradictory.

See the recent discussion about terminology in comp.lang.functional.

> It is my humble opinion that, at the end of the day, all the 'world as value'
> paradigm achieves is to enforce imperative, side effect causing and prone
> actions (sorry, perhaps some people would rather I call them functions) to be
> executed sequentially. Sure this works, but it's a little simplistic I think.
> I should emphasise that I'm not griping about Clean in particular here,
> Haskellians have the same problem with their IO monad. So does ML, in fact I
> think ML is even worse because it allows IO in ordinary functions.

The "world as value" paradigm does more than just forcing imperative actions
to be executed sequentially.  It also means that there is a clear distinction
in the type system between imperative actions and actions that do not have
side effects.  This is where Clean, Haskell, and Mercury do better than ML.

In addition, the "world as value" paradigm means that imperative actions
can be viewed as pure functions; this makes a few things a little simpler.

> So here's my idea...
> 
> 1- Forget about the 'world as value' paradigm completely. Instead invent a
> different (non functional?) way of nailing down program behaviour it terms of
> actions that must be executed in response to events external to the program.

In what way would this be an improvement on the "world as value" paradigm?

> 2- Keep the purely functional part of the language as a subset which is
> incapable of describing IO. Instead this part of the language describes
> 'side effect free' (I'll say more about that later) data transformations.
> Functions are never implemented as 'stand alone' bits of code which perform
> a reduction. They are just kept within the compiler as mathematical entities
> which may be freely manipulated, combined, transformed etc as usual. Instead,
> the functions are used to derive appropriate 'computational actions' from
> the 'action spec'. So in this sense, although the language would not be
> 'purely functional', the 'purely functional' subset of the language would be,
> in my opinion, purer than either Clean or Haskell are at present.

Why would this be any better than they way that Clean, Haskell and Mercury 
currently work?

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