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.

Advantages
- Effects can be added, removed, and interwoven without changes to code not
dealing with those effects.
Limitations
Ambiguity-Flexibility tradeoff
The extensibility of Eff
comes at the cost of some ambiguity. A useful pattern
to mitigate the ambiguity 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.
Note, however, that the extensibility can also be traded back, but that detracts
from some of the advantages. For details see section 4.1 in the
paper.
Some examples where the cost of extensibility is apparent:
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.
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 :)