Thu 30 Jun 2011
In the last few posts, I've been talking about how we can derive monads and monad transformers from comonads. Along the way we learned that there are more monads than comonads in Haskell.
The question I hope to answer this time, is whether or not we turn any Haskell Comonad into a comonad transformer.
Thu 30 Jun 2011
Last time in Monad Transformers from Comonads I showed that given any comonad we can derive the monad-transformer
newtype CoT w m a = CoT { runCoT :: w (a -> m r) -> m r
and so demonstrated that there are fewer comonads than monads in Haskell, because while every Comonad gives rise to a Monad transformer, there are Monads that do not like IO, ST s, and STM.
I want to elaborate a bit more on this topic.
Tue 28 Jun 2011
Last time, I showed that we can transform any Comonad in Haskell into a Monad in Haskell.
Today, I'll show that we can go one step further and derive a monad transformer from any comonad!
Mon 27 Jun 2011
Fri 24 Jun 2011
Last time, I said that I was going to put our cheap new free monad to work, so let's give it a shot.
Thu 23 Jun 2011
Last time, I started exploring whether or not Codensity was necessary to improve the asymptotic performance of free monads.
This time I'll show that the answer is no; we can get by with something smaller.
Thu 23 Jun 2011
A couple of years back Janis Voigtländer wrote a nice paper on how one can use the codensity monad to improve the asymptotic complexity of algorithms using the free monads. He didn't use the name Codensity in the paper, but this is essentially the meaning of his type C.
I just returned from running a workshop on domain-specific languages at McMaster University with the more than able assistance of Wren Ng Thornton. Among the many topics covered, I spent a lot of time talking about how to use free monads to build up term languages for various DSLs with simple evaluators, and then made them efficient by using Codensity.
This has been shown to be a sufficient tool for this task, but is it necessary?
