Scala Days Recap and Why the Free Monad Isn’t Free
engineering.sharethrough.com
Scala Days Recap and Why the Free Monad Isn’t Free
1–9 of 9 posts
Re: Scala Days Recap and Why the Free Monad Isn’t Free
#2In 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.
Re: Scala Days Recap and Why the Free Monad Isn’t Free
#3In 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…
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).
Re: Scala Days Recap and Why the Free Monad Isn’t Free
#4Great 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
Re: Scala Days Recap and Why the Free Monad Isn’t Free
#5In 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…
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.
Re: Scala Days Recap and Why the Free Monad Isn’t Free
#6Earlier quoted context omitted.
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) m…
> 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.
Re: Scala Days Recap and Why the Free Monad Isn’t Free
#7In 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…
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).
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.
Re: Scala Days Recap and Why the Free Monad Isn’t Free
#8Earlier quoted context omitted.
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).
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.
Re: Scala Days Recap and Why the Free Monad Isn’t Free
#9Earlier quoted context omitted.
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) m…
> 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.