independant monads used together?

Richard Uhtenwoldt [email protected]
Sat, 10 Nov 2001 17:30:55 -0800


Pixel writes:

>I must be missing something. I still don't understand what is to be done to
>mix monads.

The short answer is you can't, or you do not want to because it is not 
worth the effort.  E.g., monad transformers can be considered
a way to mix monads, but I do not believe they are worth
the effort for the type of programs you seem to want to write
(because they will have no significant benefit).

>As far as I've seen the only really used monad is IO. So I can't
>find useful examples using the standard library.
>But suppose I have GUI which interacts via the gui and has getLine' and
>print', how can i do something that:
>
>- getLine on IO, getLine' on GUI
>- verify it is the same
>- print on IO, print' on GUI
>- ...

A common approach is to give everything an IO-based type, eg,

getLine'::Window->IO String
print'::Window->String->IO ()

For more, see
http://www.haskell.org/communities/html/report.html#sect4.3.1.2

In general, if you want fine control over your program's interaction
with the outside world, you have to stay in the IO monad or --to
introduce a complexity you do not need to learn yet-- a monad with the
IO monad in its representation, eg,

  newtype MyMonad a=MyMonad (IO a)

Monads not based on the IO monad, like maybe monads and name-supply
monads and type-checking monads and the ST monad etc, are useful only in
the "non-interactive" parts of programs.  E.g., a compiler typically has
a long non-interactive part between the reading of the
source file and the writing of an object file.

Some Haskellers, eg, the ones working on purely-functional GUI
libraries, will disagree strongly with what I just said, so let me try
to head off their anger by saying that I am not certain that their
approach is inferior to mine, but I plan to stay with my approach
anyways, to see where it can lead and to cut down the size of the design
space I must search through.