monads

Every other monad comes with a transformer version, and from what I know the idea of a transformer is a generic extension of monads. Following how the other transformers are build, IOT would be something like newtype IOT m a = IOT { runIOT :: m (IO a) } for which I could make up useful applications on the spot: IOT Maybe can either do an IO action or nothing, IOT [] can build a list that can later be sequence d. So why is there no IO transformer in Haskell? (Notes: I've seen this post on Haskell Cafe , but can't make much sense of it. Also, the Hackage page for the ST transformer mentions a

... with all those new (and not so new if we count IEnumerable) monad-related stuff? interface IMonad<T> { SelectMany/Bind(); Return/Unit(); } That would allow to write functions that operate on any monadic type. Or it's not so critical? Think about what the signature for IMonad<T> 's methods would have to be. In Haskell the Monad typeclass is defined as class Monad m where (>>=) :: m a -> (a -> m b) -> m b return :: a -> m a It's tricky to translate this directly to a C# interface because you need to be able to reference the specific implementing subtype ("m a" or ISpecificMonad<a> ) within

I'm fairly comfortable now with the rest of the arrow machinery, but I don't get how loop works. It seems magical to me, and that's bad for my understanding. I also have trouble understanding mfix. When I look at a piece of code that uses rec in a proc or do block, I get confused. With regular monadic or arrow code, I can step through the computation and keep an operational picture of what's going on in my head. When I get to rec , I don't know what picture to keep! I get stuck, and I can't reason about such code. The example I'm trying to grok is from Ross Paterson's paper on arrows , the one

I know what the monads are and how to use them. What I don't understand is what makes, let's say, Option a monad? In Haskell a monad Maybe is a monad because it's instantiated from Monad class (which has at least 2 necessary functions return and bind that makes class Monad , indeed, a monad). But in Scala we've got this: sealed abstract class Option[+A] extends Product with Serializable { ... } trait Product extends Any with Equals { ... } Nothing related to a monad. If I create my own class in Scala, will it be a monad by default? Why not? Monad is a concept, an abstract interface if you will

Before you start reading: This question is not about understanding monads, but it is about identifying the limitations of the Java type system which prevents the declaration of a Monad interface. In my effort to understand monads I read this SO-answer by Eric Lippert on a question which asks about a simple explanation of monads. There, he also lists the operations which can be executed on a monad: That there is a way to take a value of an unamplified type and turn it into a value of the amplified type. That there is a way to transform operations on the unamplified type into operations on the

I am learning Haskell and trying to understand Monads. I have two questions: From what I understand, Monad is just another typeclass that declares ways to interact with data inside "containers", including Maybe , List , and IO . It seems clever and clean to implement these 3 things with one concept, but really, the point is so there can be clean error handling in a chain of functions, containers, and side effects. Is this a correct interpretation? How exactly is the problem of side-effects solved? With this concept of containers, the language essentially says anything inside the containers is

What is the difference between the map and flatMap functions of Iterable ? Here is a pretty good explanation: http://www.codecommit.com/blog/scala/scala-collections-for-the-easily-bored-part-2 Using list as an example: Map's signature is: map [B](f : (A) => B) : List[B] and flatMap's is flatMap [B](f : (A) => Iterable[B]) : List[B] So flatMap takes a type [A] and returns an iterable type [B] and map takes a type [A] and returns a type [B] This will also give you an idea that flatmap will "flatten" lists. val l = List(List(1,2,3), List(2,3,4)) println(l.map(_.toString)) // changes type from

God I hate the term "code smell", but I can't think of anything more accurate. I'm designing a high-level language & compiler to Whitespace in my spare time to learn about compiler construction, language design, and functional programming (compiler is being written in Haskell). During the code generation phase of the compiler, I have to maintain "state"-ish data as I traverse the syntax tree. For example, when compiling flow-control statements I need to generate unique names for the labels to jump to (labels generated from a counter that's passed in, updated, & returned, and the old value of

Monads can do many amazing, crazy things. They can create variables which hold a superposition of values. They can allow you to access data from the future before you compute it. They can allow you to write destructive updates, but not really. And then the continuation monad allows you to break people's minds! Ususally your own. ;-) But here's a challenge: Can you make a monad which can be paused ? data Pause s x instance Monad (Pause s) mutate :: (s -> s) -> Pause s () yield :: Pause s () step :: s -> Pause s () -> (s, Maybe (Pause s ())) The Pause monad is a kind of state monad (hence mutate