Merge pull request #5 from evenbrenden/master

Fix some typos

code/Tiles/Efficient.hs

@@ -316,7 +316,7 @@ main = do
 rasterize
     :: forall a
      . Int  -- ^ resulting width
-    -> Int  -- ^ resulting heigeht
+    -> Int  -- ^ resulting height
     -> Tile a
     -> [[a]]  -- ^ the resulting "pixels" in row-major order
 rasterize w h t = do

code/Tiles/Initial.hs

@@ -363,7 +363,7 @@ takeDrop n (a:as) = a : takeDrop n (drop n as)
 -- applicative homomorphism.
 rasterize'
     :: Int  -- ^ resulting width
-    -> Int  -- ^ resulting heigeht
+    -> Int  -- ^ resulting height
     -> Tile a
     -> Compose ZipList ZipList a  -- ^ the resulting "pixels" in row-major order
 rasterize' w h t = coerce $ rasterize w h t

prose/part1/3-scavenge-design.markdown

@@ -811,7 +811,7 @@ many inputs it consumed in completing the first branch.
 Exercise
 
 :  Give semantics for `andThen` in terms of `completes :: Challenge -> [Input] -> Bool`.
-   Show that your these semantics necessarily contradict `law:andThen/gate`.
+   Show that these semantics necessarily contradict `law:andThen/gate`.
 
 
 While there is undoubtedly an art to choosing sound observations, this is an excellent
@@ -1489,7 +1489,7 @@ with the usual identity laws:
 
 ```{.haskell law="sub/mempty"}
 ∀ (k :: Clue).
-  sub k noList = k = sub noList k
+  sub k noClue = k = sub noClue k
 ```
 
 Before going too much further, we should slow down and think through this clue design's implications. It seems reasonable to give the following law:
@@ -1846,7 +1846,7 @@ gate    :: InputFilter i -> Challenge i -> Challenge i
 -- etc.
 ```
 
-To finish up this generalization we require a function that lifts an
+To finish up this generalization we require a function that lifts a
 `CustomFilter i` into an `InputFilter i`.
 
 ```haskell
@@ -1928,7 +1928,7 @@ Verify that these are reasonable laws and that they form a monoid homomorphism
 with `empty` and `andThen`.
 
 With these changes made, the `Clue` in `step` now sticks out like a sore thumb;
-it's as the only concrete type in the signature of `step`. And as our analysis
+it's the only concrete type in the signature of `step`. And as our analysis
 earlier showed, our `Clue` type is isomorphic to a list. Let's just drop in a
 list here, but be polymorphic over its contents.
 

prose/part2/1-tiles-impl.markdown

@@ -916,7 +916,7 @@ value at the same point in a different space. This, too, is performed
 
 Exercise
 
-:  Prove `law:ap/pure/id` is satisfied by the definitions of `pure` and `(<*>)`
+:  Prove that `law:ap/pure/id` is satisfied by the definitions of `pure` and `(<*>)`
    given here.
 
 

prose/part2/2-scavenge-impl.markdown

@@ -53,7 +53,7 @@ getClues
     -> MonoidalMap [k] ClueState
 ```
 
-Also, we have a sort of "sub-algebra." corresponding to the land of user
+Also, we have a sort of "sub-algebra" corresponding to the land of user
 inputs and predicates over that input:
 
 ```haskell

prose/part3/3-quickcheck.markdown

@@ -648,7 +648,7 @@ producesAllValues gen = ioProperty $ do
       missing_cons = all_cons S.\\ gen_cons
 
   pure $ flip whenFail (null missing_cons) $ do
-    putStrLn "Generator failed to produce the following:
+    putStrLn "Generator failed to produce the following:"
     for_ missing_cons $ putStrLn . mappend "• "
 ```
 

prose/part3/4-quickspec.markdown

@@ -296,7 +296,7 @@ sum :: [Integer] -> Integer
   3. sum xs + sum ys = sum (xs ++ ys)
 ```
 
-You'll notice that there are now two function blocks in our put; the first
+You'll notice that there are now two function blocks in our output; the first
 describes the constructors in our background --- so we know what's being
 considered when generating laws --- while the second lists the actual functions
 we're interested in. Our resulting laws now all mention `sum`, just as

prose/part3/5-algebras.markdown

@@ -207,7 +207,7 @@ attempt to send emails whenever a relevant action happens, and rely on the laws
 to ensure we don't spam the user.
 
 Formally, we can write our two flavors of idempotency as follows. In the first,
-a function `f :: A -> A` is said to be idempotent if `lawn:defn: idempotent
+a function `f :: A -> A` is said to be idempotent if `law:defn: idempotent
 func` holds:
 
 ```{.haskell law="defn: idempotent func"}
@@ -480,7 +480,7 @@ Semigroups are required to fulfill only one equation, namely associativity
 That's it! The requirements for being a semigroup are non-demanding, and
 therefore, semigroups are extremely widespread. Some semigroups you're already
 familiar with include list and string concatenation, addition, multiplication,
-the boolean AND and OR operations, the `over` color mixing operation, the `min`
+the boolean AND and OR operations, the `behind` color mixing operation, the `min`
 and `max` functions, picking the first and last element in a series, and
 function composition itself. Additionally, things like combining disparate
 pieces of configuration usually form a semigroup. Semigroups appear everywhere!
@@ -696,7 +696,7 @@ which, in addition to the functor laws, must also respect:
 
 as well as be associative:
 
-```{.haskell law="fmap/snd/zap"}
+```{.haskell law="fmap/reassoc/zap"}
 ∀ (x :: a) (y :: b) (c :: z).
   fmap reassoc (zap x (zap y z)) = zap (zap x y) z
 ```