4 ms·

Which monads Haskell developers use: An exploratory study

89 points by paulcarey 6y ago

lmm 6y ago
A big advantage of the monad abstraction is that you can define custom monads to suit your business cases, but then reuse a lot of existing functionality with those monads. So looking at which "standard" monads are most popular only tells half the story.
- prionassembly 6y ago
  This is probably true of every mathematical abstraction in wide usage. 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).
  - siraben 6y ago
    > This is probably true of every mathematical abstraction in wide usage. 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] [0] https://en.wikipedia.org/wiki/Closure_operator https://en.wikipedia.org/wiki/Closure_operator
siraben 6y ago
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/ http://okmij.org/ftp/Haskell/extensible/
- bad_user 6y ago
  > 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 6y ago
    > ...with which I very much disagree with Say some more about that?
- pwm 6y ago
  > compositional and performance advantages Compositional sure, but performance? Care to elaborate?
  - siraben 6y ago
    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/ http://okmij.org/ftp/Haskell/extensible/
    - bweitzman 6y ago
      Not sure what the status of the project is, but work on https://github.com/hasura/eff https://github.com/hasura/eff is supposed to improve the performance even more!
mothsonasloth 6y ago
How many monads are in a gonad?
jakuboboza 6y ago
I used most commonly IO and State monads. but I didnt write any Haskell code for like 4 years now. So stuff could change. Maybe GHC got fixed ;)
- siraben 6y ago
  This study is about the usage of monads from the monad transformer library (mtl) across Hackage.

89 points by paulcarey 6y ago

lmm 6y ago

A big advantage of the monad abstraction is that you can define custom monads to suit your business cases, but then reuse a lot of existing functionality with those monads. So looking at which "standard" monads are most popular only tells half the story.

prionassembly 6y ago
This is probably true of every mathematical abstraction in wide usage. 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).
- siraben 6y ago
  > This is probably true of every mathematical abstraction in wide usage. 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] [0] https://en.wikipedia.org/wiki/Closure_operator https://en.wikipedia.org/wiki/Closure_operator

siraben 6y ago

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/ http://okmij.org/ftp/Haskell/extensible/

bad_user 6y ago
> 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 6y ago
  > ...with which I very much disagree with Say some more about that?
pwm 6y ago
> compositional and performance advantages Compositional sure, but performance? Care to elaborate?
- siraben 6y ago
  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/ http://okmij.org/ftp/Haskell/extensible/
  - bweitzman 6y ago
    Not sure what the status of the project is, but work on https://github.com/hasura/eff https://github.com/hasura/eff is supposed to improve the performance even more!

mothsonasloth 6y ago

How many monads are in a gonad?

jakuboboza 6y ago

I used most commonly IO and State monads. but I didnt write any Haskell code for like 4 years now. So stuff could change. Maybe GHC got fixed ;)

siraben 6y ago
This study is about the usage of monads from the monad transformer library (mtl) across Hackage.