Update 2. Leaving the monad.md

Author: Tiltman

Part 3 - Taming the sequence/2. Leaving the monad.md

@@ -1,13 +1,13 @@
 # Leaving the monad
 
-A monad is an abstract concept from functional programming that is unfamiliar to most programmers. It is beyond the scope of this guide to about teach monads in general. In www.introtorx.com we find a short definition:
+A [monad] (https://en.wikipedia.org/wiki/Monad_%28functional_programming%29) is an abstract concept from functional programming that is unfamiliar to most programmers. It is beyond the scope of this guide teaching monads. In www.introtorx.com we find a short definition:
 > Monads are a kind of abstract data type constructor that encapsulate program logic instead of data in the domain model.
 
-Monads are of interest to us, because Rx, and more specifically the observable, is a monad. Rx code declares what needs to be done but the actual processing happens not when Rx statements are executed, but rather when values are emitted. Readers may find it interesting to read more about monads in general. For this guide, when refering to monads the reader only needs to think about the observable.
+Monads are of interest to us, because the observable is a monad. Rx code declares what needs to be done but the actual processing happens not when Rx statements are executed, but rather when values are emitted. Readers may find it interesting to read more about monads in general. For this guide, when refering to monads the reader only needs to think about the observable.
 
 ## Why leave the monad
 
-There are two main reasons one may want to leave the monad. The first reason is that a new Rx developer will still be more comfortable in more traditional paradigms. Doing parts of the computation in a different paradigm may enable you to get some parts working, while you're still figuring out how to do things in Rx. Another reason to leave the monad is to interact with components and libraries that weren't designed with Rx in mind. When refactoring existing code into Rx, it may be useful to have Rx behave in a blocking way.
+There are two main reasons one may want to leave the monad. The first reason is that a new Rx developer will still be more comfortable in more traditional paradigms. Doing parts of the computation in a different paradigm may enable you to get some parts working, while you're still figuring out how to do things in Rx. The second reason is that we usually interact with components and libraries that weren't designed with Rx in mind. When refactoring existing code into Rx, it may be useful to have Rx behave in a blocking way.
 
 ## BlockingObservable
 
@@ -25,7 +25,7 @@ public static <T> BlockingObservable<T> from(Observable<? extends T> o)
 
 ### forEach
 
-`Observable` has a method called `foreEach`. `forEach` is defined as an alias to `subscribe`, with the main difference being that it doesn't return a `Subscription`.
+`Observable` has a method called `forEach`. `forEach` is defined as an alias to `subscribe`, with the main difference being that it doesn't return a `Subscription`.
 
 Consider this example
 
@@ -49,7 +49,7 @@ Subscribed
 
 The code here behaves like `subscribe` would. First you register an observer (no overload for `forEach` accepts `Observer`, but the semantics are the same). Execution then proceeds to print "Subscribed" and exits our snippet. As values are emitted (the first one with a 100ms delay), they are passed to our observer for processing.
 
-`BlockingObservable` doesn't have a `subscribe` function, but it has `forEach`. Lets see the same example with `BLockingObservable`
+`BlockingObservable` doesn't have a `subscribe` function, but it has `forEach`. Let's see the same example with `BLockingObservable`
 
 ```java
 Observable<Long> values = Observable.interval(100, TimeUnit.MILLISECONDS);
@@ -70,7 +70,7 @@ System.out.println("Subscribed");
 Subscribed
 ```
 
-We see here that the call to `forEach` blocked until the observable completed. Another difference is that there can be no handlers for `onError` and `onCompleted`. `onCompleted` is a given if the execution continues, while exceptions will be thrown into the runtime to be caught:
+We see here that the call to `forEach` blocked until the observable completed. Another difference is that there can be no handlers for `onError` and `onCompleted`. `onCompleted` is a given if the execution completes, while exceptions will be thrown into the runtime to be caught:
 
 ```java
 Observable<Long> values = Observable.error(new Exception("Oops"));