extensible-effects: An Alternative to Monad Transformers

[ control, effect, library, mit ] [ Propose Tags ]

This package introduces datatypes for typeclass-constrained effects, as an alternative to monad-transformer based (datatype-constrained) approach of multi-layered effects. For more information, see the original paper at http://okmij.org/ftp/Haskell/extensible/exteff.pdf. Any help is appreciated!


[Skip to Readme]
Versions 1.0, 1.1.0, 1.2.0, 1.2.1, 1.4.1, 1.5.0, 1.6.0, 1.7.1, 1.7.1.0, 1.7.1.1, 1.7.1.2, 1.7.2.1, 1.8.0.0, 1.8.1.0, 1.9.0.0, 1.9.0.1, 1.9.1.0, 1.9.2.2, 1.10.0.1, 1.11.0.0, 1.11.0.1, 1.11.0.2, 1.11.0.3, 1.11.0.4, 1.11.1.0, 2.0.0.0, 2.0.0.2, 2.0.1.0, 2.1.0.0, 2.2.1.0, 2.3.0.0, 2.3.0.1, 2.4.0.0, 2.5.0.0, 2.5.1.0, 2.5.1.2, 2.5.2.0, 2.5.3.0, 2.6.0.0, 2.6.0.1, 2.6.0.2, 2.6.0.3, 2.6.1.0, 2.6.1.1, 2.6.2.0, 2.6.3.0, 3.0.0.0, 3.1.0.0, 3.1.0.1 (info)
Dependencies base (>=4.7 && <4.12), monad-control (==1.0.*), transformers-base (==0.4.*) [details]
License MIT
Author Oleg Kiselyov, Amr Sabry, Cameron Swords, Ben Foppa
Maintainer suhailshergill@gmail.com
Category Control, Effect
Home page https://github.com/suhailshergill/extensible-effects
Source repo head: git clone https://github.com/suhailshergill/extensible-effects.git
Uploaded by shergill at Sun Apr 1 06:17:06 UTC 2018
Distributions NixOS:3.1.0.1
Downloads 11516 total (83 in the last 30 days)
Rating 2.25 (votes: 2) [estimated by rule of succession]
Your Rating
  • λ
  • λ
  • λ
Status Docs available [build log]
Last success reported on 2018-04-14 [all 1 reports]
Hackage Matrix CI

Modules

[Index]

Flags

NameDescriptionDefaultType
lib-werrorDisabledManual
force-openunion-51

Force usage of OpenUnion51.hs implementation

DisabledManual

Use -f <flag> to enable a flag, or -f -<flag> to disable that flag. More info

Downloads

Maintainer's Corner

For package maintainers and hackage trustees


Readme for extensible-effects-2.5.1.2

[back to package description]

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 <a href="https://gitter.im/suhailshergill/extensible-effects">https://gitter.im/suhailshergill/extensible-effects</a> Stories in Ready Stories in progress

Advantages

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

Limitations

Current implementation only supports GHC version 7.8 and above

This is not a fundamental limitation of the design or the approach, but there is an overhead with making the code compatible across a large number of GHC versions. If this is needed, patches are welcome :)

Disadvantages

Ambiguity-Flexibility tradeoff

A useful pattern to manage the ambiguity-flexibility tradeoff is to specialize the call to the handler of effects using type application or type annotation. Examples of this pattern can be seen in Example/Test.hs.

  • The extensibility of Eff 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.