Scala Days Recap and Why the Free Monad Isn’t Free | Hacker News Reader

Scala Days Recap and Why the Free Monad Isn’t Free

engineering.sharethrough.com

30 pointscheezsndwch8 comments

In the Haskell community there was a period of time where free monads and their equivalents that had different performance characteristics were a fad. The buzz has passed but they remain a good tool if you ever need to evaluate your expressions using more than one interpretation. Really, that's all the free monad gives you: syntax without semantics. Your semantics come from the monad algebra you choose to reduce the expression. If you are only ever evaluating under one semantics, the free monad pattern is overkill.

Regular typeclasses can also give you just syntax w/ capabilities for different semantics; what free monads actually give you above typeclasses is a bit more subtle (i.e. even less).

Type class instance parameters must be explicit in Scala, whereas Haskell can usually infer them. That might make a free monad approach more interesting in Scala.

However, if you really want to introduce this complexity in Scala, you will probably first write some nice high-level code, then discover that it causes a stack overflow, then have to learn about the TailRec monad, figure out how to stack your (free-like) monad on top of it, therefore learn monad transformers, which you probably wanted to avoid by using a free-like monad. A library may solve part of the problem for you, but you will have to be aware of your own stack usage all the time. And when it works you should tune your JVM garbage collector for many (many) short-lived objects.

I would either keep it simple in Scala or choose a language that supports this kind of abstraction in a less painful way.

> Type class instance parameters must be explicit in Scala

In Scala, wouldn't this be solved with implicits? i.e. implicit 'instances' are in Singleton Objects that one simply brings into scope with an import.

In Scala, the implicit arguments are implicit, yes, but the parameter is not. You will have to declare the implicit parameter, even if you omit a type signature.

I think I forgot to mention the lack of type class coherence. That's also something you should be aware of when you start using type classes.

I think that's the difference between initial encoding (free monad) and finally tagless ala Oleg. They're different but they get you a lot of the same stuff. Finally tagless never got a bandwagon tho.

In haskell, I think the mtl has quite a bandwagon.

Great post and excellent talk. Wish I saw a them couple of months earlier. Highly recommended to anyone getting into this kind of thing in scala

Reply on news.ycombinator.com