Module documentation for 188.8.131.52
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.
Effects can be added, removed, and interwoven without changes to code not dealing with those effects.
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 :)
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
Effcomes 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
getStatefunctions can't be grouped with some
class Get t a where ask :: Member (t a) r => Eff r a
askis inherently ambiguous, since the type signature only provides a constraint on
t, and nothing more. To specify fully, a parameter involving the type
twould 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.