extensible-effects

An Alternative to Monad Transformers

https://github.com/suhailshergill/extensible-effects

Version on this page:2.0.0.2
LTS Haskell 23.28:5.0.0.1@rev:1
Stackage Nightly 2024-12-09:5.0.0.1@rev:1
Latest on Hackage:5.0.0.1@rev:1

See all snapshots extensible-effects appears in

MIT licensed by Oleg Kiselyov, Amr Sabry, Cameron Swords, Ben Foppa
Maintained by [email protected]
This version can be pinned in stack with:extensible-effects-2.0.0.2@sha256:d3ca24f7ab2c1ef4cc341b8ca338fd195b92f2ad4f9448abfb11da62fc62ec6d,5656

Module documentation for 2.0.0.2

extensible-effects is based on the work Extensible Effects: An Alternative to Monad Transformers. Please read the paper and the followup freer paper for details. Additional explanation behind the approach can be found on Oleg’s website.

Build Status Join the chat at https://gitter.im/suhailshergill/extensible-effects Stories in Ready Stories in progress

Advantages

  • Effects can be added, removed, and interwoven without changes to code not dealing with those effects.

Disadvantages

Current implementation only supports GHC version 7.8 and above

Ambiguity-Flexibility tradeoff

  • The extensibility comes at the cost of some ambiguity. Note, however, that the extensibility can be traded back, but that detracts from some of the advantages. For details see section 4.1 in the paper. This issue manifests itself in a few ways:

    • Common functions can’t be grouped using typeclasses, e.g. the ask and getState functions can’t be grouped with some

      class Get t a where
  ask :: Member (t a) r => Eff r a

      ask is inherently ambiguous, since the type signature only provides a constraint on t, and nothing more. To specify fully, a parameter involving the type t would need to be added, which would defeat the point of having the grouping in the first place.

    • Code requires greater number of type annotations. For details see #31.