Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
environment idiom
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 2004-12-13 (14:10)
From: skaller <skaller@u...>
Subject: Re: [Caml-list] environment idiom
On Mon, 2004-12-13 at 23:09, Jacques Garrigue wrote:
> From: Thomas Fischbacher <Thomas.Fischbacher@Physik.Uni-Muenchen.DE>

> OK, so probably we almost agree.
> Three days ago I was about to answer John that indeed he has a good
> point, but he seems to ignore completely the other advantages of
> monads, like the fact you can cleanly mix stateful code with pure
> code, keeping the two separate.

I'm ignoring them only in the sense this particular discussion
isn't about that.

> My real curiosity was about the kind of compositional abstractions one
> would use with stateful computations. It seems to me that the presence
> of state itself makes it more difficult to compose cleanly.

I would contend that is just a lack of theoretical understanding
of how to do stateful programming.

If you consider streams, and more generally, coinductive 
types to be stateful, then you can look at a
symmetrical integration of the two concepts in a 
programming language -- Google for Charity.

The language is weak -- functions aren't first class and it
isn't Turing complete, but on the flip side all Charity
programs are sure to terminate.

>  While being no expert of
> the question, this seems to be a tendency of monads: they are
> so comfortable that they tend to pollute everything, diluting the
> advantage of knowing exactly what is functional. But how can you stop
> people from going the easy way?

You already know the answer I suspect -- better theory.
It's one thing, for example, to find an FP is easier to use,
and then to learn the superior compositional properties
are the reason, and they depend on transparency .. but another
to finally see a *theoretical* account of why this is so.
This makes it easier to calculate a good solution where
previously it looked hard -- i.e. you can't stop people
going the easy way, so make the right way easier :)

[BTW: Isn't Haskell slated to get Arrows to replace monads?]

John Skaller,
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language