diff --git a/README.md b/README.md
--- a/README.md
+++ b/README.md
@@ -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).
diff --git a/extensible-effects.cabal b/extensible-effects.cabal
--- a/extensible-effects.cabal
+++ b/extensible-effects.cabal
@@ -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