diff --git a/doc/examples/PoorMansConcurrency.hs b/doc/examples/PoorMansConcurrency.hs
--- a/doc/examples/PoorMansConcurrency.hs
+++ b/doc/examples/PoorMansConcurrency.hs
@@ -41,6 +41,7 @@
 runProcess :: Monad m => Process m a -> m ()
 runProcess m = schedule [m]
     where
+    schedule :: Monad m => [Process m a] -> m ()
     schedule (x:xs) = run (view x) xs
 
     run :: Monad m => ProgramView (ProcessI m) a -> [Process m a] -> m ()
diff --git a/operational.cabal b/operational.cabal
--- a/operational.cabal
+++ b/operational.cabal
@@ -1,5 +1,5 @@
 Name:               operational
-Version:            0.2.1.2
+Version:            0.2.1.3
 Synopsis:           Implementation of difficult monads made easy
                     with operational semantics.
 Description:
@@ -35,7 +35,7 @@
 
 Library
     hs-source-dirs:     src
-    build-depends:      base == 4.* , mtl >= 1.1 && < 2.1.0
+    build-depends:      base == 4.* , mtl >= 1.1 && < 2.2.0
     ghc-options:        -Wall
     extensions:         GADTs, UndecidableInstances,
                         MultiParamTypeClasses, FlexibleInstances
diff --git a/src/Control/Monad/Operational.hs b/src/Control/Monad/Operational.hs
--- a/src/Control/Monad/Operational.hs
+++ b/src/Control/Monad/Operational.hs
@@ -96,7 +96,8 @@
 or you can keep a log of all user inputs on the client side an replay them,
 and so on. Moreover, you can implement different @run@ functions
 for one and the same custom monad, which is useful for testing.
-Also not that the result of the @run@ function does not need to be a monad at all.
+Also note that the result type of the @run@ function does not need to
+be a monad at all.
 
 In essence, your custom monad allows you to express
 your web application as a simple imperative program,