The extensible-effects package

[ Tags: 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]

Properties

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 (info)
Dependencies base (>=4.6 && <5), transformers (>=0.3 && <0.5), 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/RobotGymnast/extensible-effects
Source repo head: git clone https://github.com/RobotGymnast/extensible-effects.git
Uploaded Thu Nov 27 11:29:21 UTC 2014 by shergill
Distributions LTSHaskell:2.1.0.0, NixOS:2.4.0.0, Stackage:2.4.0.0, openSUSE:2.1.0.0
Downloads 9723 total (206 in the last 30 days)
Rating 2.25 (votes: 2) [estimated by rule of succession]
Your Rating
  • λ
  • λ
  • λ
Status Docs uploaded by user
Build status unknown [no reports yet]
Hackage Matrix CI

Modules

[Index]

Downloads

Maintainer's Corner

For package maintainers and hackage trustees


Readme for extensible-effects-1.7.2.1

[back to package description]

extensible-effects is based on the work Extensible Effects: An Alternative to Monad Transformers. Please read the paper for details.

Advantages

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

Disadvantages

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

  • Requires a Typeable instance on the return type.

  • Neither Eff nor (:>) has a Typeable instance, and can thus often not be used as a return type (e.g. State type) for other Effs.