extensible-effects 2.6.0.0 → 2.6.0.1

raw patch · 2 files changed

+21/−22 lines, 2 filesPVP ok

version bump matches the API change (PVP)

API changes (from Hackage documentation)

Files

• README.md +20/−21
• extensible-effects.cabal +1/−1

@@ -21,30 +21,29 @@ 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](https://ghc.haskell.org/trac/ghc/wiki/TypeApplication) or-type annotation. Examples of this pattern can be seen in+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](https://ghc.haskell.org/trac/ghc/wiki/TypeApplication)+or type annotation. Examples of this pattern can be seen in [Example/Test.hs](./test/Control/Eff/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](http://okmij.org/ftp/Haskell/extensible/exteff.pdf). 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+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](http://okmij.org/ftp/Haskell/extensible/exteff.pdf). -          class Get t a where-            ask :: Member (t a) r => Eff r a+Some examples where the cost of extensibility is apparent: -      `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](https://github.com/suhailshergill/extensible-effects/issues/31).+  * 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](https://github.com/suhailshergill/extensible-effects/issues/31).

@@ -6,7 +6,7 @@ -- PVP summary:      +-+------- breaking API changes --                   | | +----- non-breaking API additions --                   | | | +--- code changes with no API change-version:             2.6.0.0+version:             2.6.0.1  -- A short (one-line) description of the package. synopsis:            An Alternative to Monad Transformers