independant monads used together?

Pixel
I'm trying to achieve something like (ocaml) [code deleted] which is a foldl on 2 iterators. I've managed to use monads for one iterator, but i completly miss the way to work with 2 monads. Is there really no other solution than creating a monad over the 2 iterators??
Why monadic iterators at all? One of the great things about lazy lists is they encapsulate iteration nicely: Elements can be generated as they're consumed. This is pretty much what a regular folding zip would buy you: zipFoldl f z a b = foldl (\sofar (a,b) -> f sofar a b) z (zip a b) You're having trouble combining the results of two state monads precisely because they're manipulating two *independent* pieces of state, and you're trying to combine the *states* of the monads in some fashion. What should the type of the result of the manipulation be? Where are the initial states of each computation coming from? Some computations really are much more easily done in the value domain then under a wrapper like a monad which obscures their real structure. -Jan-Willem Maessen jmaessen@mit.edu

Jan-Willem Maessen
Pixel
asks: I'm trying to achieve something like (ocaml) [code deleted] which is a foldl on 2 iterators. I've managed to use monads for one iterator, but i completly miss the way to work with 2 monads. Is there really no other solution than creating a monad over the 2 iterators??
Why monadic iterators at all? One of the great things about lazy lists is they encapsulate iteration nicely: Elements can be generated as they're consumed.
oops, i forgot this. /me was trying to translate from a language to another without thinking :-( of course, an iterator over a structure is a "to_list" function. /me bad [...]
You're having trouble combining the results of two state monads precisely because they're manipulating two *independent* pieces of state, and you're trying to combine the *states* of the monads in some fashion. What should the type of the result of the manipulation be? Where are the initial states of each computation coming from?
I don't quite understand those questions. Combining states is a common task in imperative world. I must be missing something. I still don't understand what is to be done to mix monads. 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 - ...
Some computations really are much more easily done in the value domain then under a wrapper like a monad which obscures their real structure.
Well, the intention was to hide the real structure :) But i agree i missed something simple... thanks, Pixel.

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.
participants (3)
-
Jan-Willem Maessen
-
Pixel
-
Richard Uhtenwoldt