
Scala Days Recap and Why the Free Monad Isn’t Free - cheezsndwch
http://engineering.sharethrough.com/blog/2016/07/26/scala-days-recap/
======
danharaj
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.

~~~
platz
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).

~~~
roberthensing
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.

~~~
platz
> 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.

~~~
roberthensing
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.

------
AzzieElbab
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

