Hacker News new | ask | show | jobs
by noelwelsh 4610 days ago
Clearest blog post I've read on the Reader monad in Scala. This is something I can see coming to our code base very soon.

The next step for us is monad transformers in Scalaz. We are going to end up with something like Future[Reader[Writer[Problem \/ Result]]] (a few type parameters are missing there; hopefully you get the idea). Monad transformers give a way to flatten this stack of monads into a single monad, which saves a lot of unnecessary wrapping and unwrapping in code. I haven't yet worked out the all the details of using them, though. Should probably do a blog post when I do :-)

2 comments

I've been thinking about using scalaz for a while now. My main concern about the above pattern is the type complexity that will arise. I would love to learn more about monad transformers and how they help out with that issue.
Here's what I've written so far:

https://raw.github.com/noelwelsh/noelwelsh.com/master/_draft...

A bit of searching will find a few talks, blog posts, and Stackoverflow answers. I haven't found anything I really like, which is why I'm writing the post.

I look forward to that blog post. In order to use Scalaz's monad transformers with scala.concurrent.Future, would I have to write my own monad instance for it, or is there a way to re-use the one from scalaz.concurrent?
The scalaz-contrib library has a Monad instance for scala.concurrent.Future: https://github.com/typelevel/scalaz-contrib/blob/master/scal...
A scalaz monad instance for scala.concurrent.Future can be written in about two lines.