monads

This question already has answers here : Closed last year . Is there a monad that doesn't have a corresponding monad transformer (except IO)? (4 answers) Monad transformers are known for all standard monads (Reader, Writer, State, Cont, List, etc.), but each of these monad transformers works in a slightly different way. There is no general method or formula for constructing a monad transformer given a definition of a type constructor with a monad instance. So, it is not assured that a monad data type designed according to some arbitrary business requirements will have a monad transformer. Is

I've always enjoyed the following intuitive explanation of a monad's power relative to a functor: a monad can change shape; a functor cannot. For example: length $ fmap f [1,2,3] always equals 3 . With a monad, however, length $ [1,2,3] >>= g will often not equal 3 . For example, if g is defined as: g :: (Num a) => a -> [a] g x = if x==2 then [] else [x] then [1,2,3] >>= g is equal to [1,3] . The thing that troubles me slightly, is the type signature of g . It seems impossible to define a function which changes the shape of the input, with a generic monadic type such as: h :: (Monad m, Num a)

I know that Haskell's do x <- [1, 2, 3] y <- [7, 8, 9] let z = (x + y) return z can be expressed in Scala as for { x <- List(1, 2, 3) y <- List(7, 8, 9) z = x + y } yield z But, especially with monads, Haskell often has statements inside the do block that don't correspond to either <- or = . For example, here's some code from Pandoc that uses Parsec to parse something from a string. -- | Parse contents of 'str' using 'parser' and return result. parseFromString :: GenParser tok st a -> [tok] -> GenParser tok st a parseFromString parser str = do oldPos <- getPosition oldInput <- getInput

Conceptually, it seems that a computation that performs output is very different from one that performs input only. The latter is, in one sense, much purer. I, for one, would like to have a way to separate the input only parts of my programme from the ones that might actually write something out. So, why is there no input only Monad? Any reason why it wouldn't work to have an I monad (and an O Monad, which could be combined into the IO Monad)? Edit : I mostly meant input as reading files, not interacting with the user. This is also my use case, where I can assume that input files do not change

I have the following function for walking around "edges" of the "graph" of my game world. It alters the state of the world--specifically, the player's location. I need to report a message alerting the player of their change in location as well. So I could either return a tuple of (message, newWorld), or I could use a State monad. (Right? I'm new to this stuff.) Here's my attempt at the monad approach: walk dir = do world <- get let attempt = filter (\e -> edgeDirection e == dir) $ edges edges = (worldEdges world) M.! playerLoc playerLoc = playerLocation $ worldPlayer world case attempt of [] -