[siraben]

Haskeller here, some observations:

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

[0] http://okmij.org/ftp/Haskell/extensible/

[bad_user]

> One ought to be able to express more nuanced side effects such as network/disk access or console I/O.

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

[asplake]

> ...with which I very much disagree with

Say some more about that?

[senorsmile]

> One ought to be able to express more nuanced side effects such as network/disk access or console I/O

IIRC, this is one of the things that Idris brings to the table.

[pwm]

> compositional and performance advantages

Compositional sure, but performance? Care to elaborate?

[siraben]

I'd point you to Oleg Kiselyov's page on Extensible Effects[0]. Here's a quote:

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.

[0] http://okmij.org/ftp/Haskell/extensible/

[bweitzman]

Not sure what the status of the project is, but work on https://github.com/hasura/eff is supposed to improve the performance even more!