sketches/hierarchical-free-monads-mostly-pointless at master · effectfully-ou/sketches · GitHub
This is a response to Hierarchical Free Monads: The Most Developed Approach In Haskell. The article makes some bold claims, but it builds on an initial straw man argument that with FT one has to enumerate all individual effects of a function in its type signature, which is not true.
Please note that this post is not meant to give advice on how to structure production code in Haskell. I merely take the code written in the original article and show how it can be transformed into something more ergonomic and concise.
Although Free Monads require some work on the language definition and implementation levels, this approach doesn't bring extra boilerplate into the business logic layer. This is good because boilerplate in the business logic costs much more. Let's compare this for FT and HFM.
While the bodies of the two functions are pretty much the same there is a significant difference in the function definitions. FT requires you to specify a list of constraints. The more effects you have the more constraints will be there. Normally, business logic of a regular web service consists of dozens if not hundreds functions, and typing this kind of boilerplate makes coding extremely annoying. It doesn't buy anything useful.
