@@ -50,9 +50,9 @@ tricky to do. This also leads to the cyclic dependencies issue.
5050
5151### cyclic dependencies
5252
53−Because the Haskell builder in `nixpkgs` exposes packages at the
54−package level, if packages mutually depend on each other through tests
55−and libraries, lead to cyclic dependencies that nix can't resolve. By
53+The Haskell builder in `nixpkgs` exposes packages at the
54+package level. If packages mutually depend on each other through tests
55+and libraries, this leads to cyclic dependencies that nix can't resolve. By
5656exposing the components to nix as separate derivations this will only
5757occur if you have mutually dependent components.
5858
@@ -73,17 +73,17 @@ the optimum.
7373
7474### more logic in nix
7575
76−The `cabal2nix` tool has a resolver that resolved system dependencies
77−and licenses to values in `nixpkgs`. This logic end up being a simple
78−dictionary lookup and can be a simple nix expression. This also
76+The `cabal2nix` tool has a resolver that resolves system dependencies
77+and licenses to values in `nixpkgs`. This logic ends up being a simple
78+dictionary lookup and therefore can be a simple nix expression. This also
7979offloads some of the work the cabal to nix translation tool needs to
8080do into nix, and as such if changes are necessary (or needed to be
8181performed ad hoc) there is no need to rebuild the conversion tool and
8282subsequently mark every derived expression as out of date.
8383
84−### decoupleing
84+### decoupling
8585
86−Finally by treating Haskell.nix and nixpkgs as separate entities we
86+Finally, by treating Haskell.nix and nixpkgs as separate entities we
8787can decouple the Haskell packages and infrastructure from the nixpkgs
8888package set, and rely on it to provide us with system packages while
8989staying up to date with Haskell packages from hackage while retaining