On Mon, 2004-12-13 at 19:56, Thomas Fischbacher wrote:
> On Sun, 12 Dec 2004, Michael Walter wrote:
> 
> > Again I believe we are talking about different kinds of "purity".
> > Thomas is obviously right in that the StateTransformer monad (modulo
> > unsafe conversions) is pure, you are obviously right in the
> > (different) point that _running_ an IO fragment has side effects.
> 
> The key issue is: by not doing I/O, but talking about plans how to do I/O, 
> you go to a higher level of abstraction that allows you to do magic with 
> such plans which you just plainly miss if you only know the imperative 
> ways. It's just like everyone knows how to add (i.e. arithmetics), but 
> once you learned to talk about properties of addition (i.e. algebra), you 
> have a much richer point of view that allows you to do quite miraculous 
> things.
> 
> Of course, it's possible to just forget about all that and fall back to 
> transliterating imperative code to IO monad code,

Right. So, how can you distinguish these two ways of programming?

I'm not claiming purity, transparency, or monads are bad,
contrarily it's great stuff! But as usual, with greater power
you lose something.

> It's just the same with Haskell and the IO monad.

So again the question is -- can you *characterise* better,
the good uses and the bad ones? Perhaps you can do this
by examining the higher order abstraction being implemented
and see if that is transparent or not?

With Haskell you have a *formalised* system for building
combinators (unlike Ocaml where you can still make them,
but it's a technique, not a language feature).

Given that you can probably formalise the properties
of the machinery you can build with them. The ST monad
is so powerful it provides a general way to do procedural
programming .. IMHO that isn't at all bad. Not all procedural
code is bad :) But the same caveats probably apply to both
ordinary procedural code and a monadic version.

The main diffence is probably that *todays* Haskell programmers
will probably use the monad sparingly, making as much code
ordinary functional code as possible.

But if you go around yelling 'FP is the magic bullet'
and then 'Haskell can do procedural programming too -- but
it is magical, when you do it is makes procedural code
referentially transparent' .. then what happens?

You'll get people that literally translate C code into
ST monadic Haskell mechanically and claim their code
is better now .. :)

Anyhow I don't wish to argue that monads or FP is bad,
contrarily, I would like to learn more how to properly
characterise properties like transparency -- the ST monad
(and IO) clearly show that you can simultaneously have
and not have transparency, purity, etc depending on 
your view. So perhaps you can help define what I mean
by view .. because I only have a vague intuition what
it means.

-- 
John Skaller, mailto:skaller@users.sf.net
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net