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. _______________________________________________ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
