- Not surprised that the state monad is the most commonly used one, it essentially acts as an escape hatch to write more imperative-looking code
- List monad least used, probably due to the fact that Haskell has list comprehensions
- Continuation monad is second least used, much like how many programmers find Scheme's call/cc unintuitive, continuations can be complex conceptually and have specific use cases that don't really appear in industry
- The Error monad in mtl has been deprecated in favor of Except, looks like there's still many packages left to update
Overall I'd say that mtl has penetrated quite well into the Haskell community, any intermediate Haskeller likely knows it. However, I hope that in the future more people end up using effect libraries such as fused-effects and polysemy (based on the work on extensible effects[0]) which have compositional and performance advantages.
Also, one common complaint from the effects community is how the IO monad is a "sin bin" (as SPJ describes it) of effects. One ought to be able to express more nuanced side effects such as network/disk access or console I/O.
When designing a program we should start thinking what effect we want to achieve rather than which monad transformer to use. Instead of jumping straight to StateT and so on, we ought to identify what transformation on the world and its resources we wish to effect.
That’s one way of solving the issue, but is IMO overkill. It doesn’t tell you much about what side effects can be executed out of order, in parallel, etc.
It’s also yet another encapsulation leak, although I know Haskell devs have this mentality that the signature should describe the implementation perfectly (principle of least power), with which I very much disagree with.
Another way is to not describe IO-like values at all.
In many cases you can describe a data structure that can later be materialized into an IO by an interpreter (e.g Free Applicative/Monad would be one way of doing it).
Say some more about that?
IIRC, this is one of the things that Idris brings to the table.
Compositional sure, but performance? Care to elaborate?
Thanks to the Freer monad construction and the representation of the continuation as an efficient sequence structure, extensible effects have good performance even for relatively short monad stacks, and algorithmically better performance than monad transformers for longer stacks.
Essentially the performance improvement comes when you need to handle a nested effect, with EE you can access the handler in amortized constant time (with a type-aligned queue), instead of propagating the request up the handlers.
A big advantage of the probability abstraction (as a "partial knowledge" concept supported by Dutch Book/sure bet arguments) is that you can define probability distributions to suit your business cases but then reuse a lot of existing algorithms and even theorems (cutting down on computation).
After learning the categorical definition of monads and how they arise in math, I've noticed that programmers tend to have a very operational view of monads, when they are more general than the examples in functional programming.
A good example that came up in a propositional logic class was[0]
but I didnt write any Haskell code for like 4 years now. So stuff could change. Maybe GHC got fixed ;)
