Fix typos (happi#57)

* Fix tuple representation
* Fix typo 'H' -> 'h'
* Typo fixes in chapters 4 and 5

chapters/beam.asciidoc

@@ -30,7 +30,7 @@ stack machine, the BEAM is a register machine loosely based on WAM
 first pushed to the working stack, then the instruction pops its
 arguments and then it pushes the result on the stack.
 
-Stack machines are quite popular among virtual machine- and
+Stack machines are quite popular among virtual machine and
 programming language implementers since they are quite easy to
 generate code for, and the code becomes very compact. The compiler
 does not need to do any register allocation, and most operations do
@@ -94,13 +94,13 @@ an exercise for the reader.
 
 Anyway, the BEAM is *not* a stack machine, it is a _register machine_.
 In a register machine instruction operands are stored in registers
-instead of the stack, and the result of an operation usually end up
+instead of the stack, and the result of an operation usually ends up
 in a specific register.
 
 Most register machines do still have a stack used for passing arguments
 to functions and saving return addresses. BEAM has both a stack and
 registers, but just as in WAM the stack slots are accessible through
-registers called Y-registers. BEAM also have a number of X-registers,
+registers called Y-registers. BEAM also has a number of X-registers,
 and a special register X0 (sometimes also called R0) which works as
 an accumulator where results are stored.
 
@@ -185,7 +185,7 @@ _{move,{x,1},{y,0}}_ (read as move x1 to y0 or in imperative style: y0
 The id function (at label f4) is then called by 
 _{call,1,{f,4}}_. (We will come back to what the argument "1" stands for later.)
 Then the result of the call (now in X0)
-need to be saved on the stack (Y0), but the argument _B_
+needs to be saved on the stack (Y0), but the argument _B_
 is saved in Y0 so the BEAM does a bit of shuffling:
 
 Except for the x and y registers, there are a number of special
@@ -598,7 +598,7 @@ this by keeping track of how long a process has been running. This is
 done by counting _reductions_. The term originaly comes from the
 mathematical term beta-reduction used in lambda calculus.
 
-The definition of a reduction in BEAM not very specific, but we can
+The definition of a reduction in BEAM is not very specific, but we can
 see it as a small piece of work, which shouldn't take _too long_.
 Each function call is counted as a reduction, and BEAM does a test
 upon entry to each function if the process has used up all its

chapters/type_system.asciidoc

@@ -62,7 +62,7 @@ arithmetically, i.e. by first converting them to the same precision.
 
 The same is true when comparing for equality, thus #{1 => 1.0} == #{1 => 1} but #{1.0 => 1} /= #{1 => 1}.
 
-In Erlang versions prior to 18 keys where also compared
+In Erlang versions prior to 18 keys were also compared
 arithmetically.
 
 Erlang is dynamically typed. That is, types will be checked at
@@ -209,9 +209,10 @@ lists of Unicode code points. For strings in latin-1 there is no
 difference since latin-1 is a subset of Unicode.
 // Describe Unicode code points better. Is the subset thing true?
 
-The string "Hello" might look like this in memory:
+The string "hello" might look like this in memory:
 
-.Representation of the string "Hello" on a 32 bit machine.
+.Representation of the string "hello" on a 32 bit machine.
+[shaape]
 ----
 
  hend ->     +-------- -------- -------- --------+
@@ -222,7 +223,7 @@ The string "Hello" might look like this in memory:
                                                                                   |
  htop ->     |                                   |                                |
          132 |00000000 00000000 00000000 01111001| 120 + list tag  -------------- | -+
-         128 |00000000 00000000 00000110 10001111| (H) 104 bsl 4 + small int tag <+  |
+         128 |00000000 00000000 00000110 10001111| (h) 104 bsl 4 + small int tag <+  |
          124 |00000000 00000000 00000000 01110001| 112 + list tag  ----------------- | -+
          120 |00000000 00000000 00000110 01011111| (e) 101 bsl 4 + small int tag <---+  | 
          116 |00000000 00000000 00000000 01110001| 112 + list tag  -------------------- | -+
@@ -268,6 +269,7 @@ element in the following words. The empty tuple +{}+ is stored just as
 the word 0 (header tag 0, tuple tag 0000, and arity 0).
 
 .Representation of the tuple {104,101,108,108,111} on a 32 bit machine.
+[shaape]
 ----
 
  hend ->     +-------- -------- -------- --------+
@@ -281,22 +283,22 @@ the word 0 (header tag 0, tuple tag 0000, and arity 0).
          144 |00000000 00000000 00000110 11001111| (l) 108 bsl 4 + small int tag  |
          140 |00000000 00000000 00000110 11001111| (l) 108 bsl 4 + small int tag  |
          136 |00000000 00000000 00000110 01011111| (e) 101 bsl 4 + small int tag  | 
-         132 |00000000 00000000 00000110 10001111| (H) 104 bsl 4 + small int tag  |
-         128 |00000000 00000000 00000000 10100000| 5 bsl 6 + tuple & header tag <-+
+         132 |00000000 00000000 00000110 10001111| (h) 104 bsl 4 + small int tag  |
+         128 |00000000 00000000 00000001 01000000| 5 bsl 6 + tuple & header tag <-+
              |                ...                |
  heap ->     +-----------------------------------+
 
 ----
 
-A _binary_ is an imutable array of bytes. There are four types of
+A _binary_ is an immutable array of bytes. There are four types of
 internal representations of _binaries_. The two types _heap binaries_
 and _refc binaries_ contains binary data. The other two types, _sub
-binaries_ and _match contexts_ (the BINARY_AGREGATE tag) are smaller
+binaries_ and _match contexts_ (the BINARY_AGGREGATE tag) are smaller
 references into one of the other two types.
 
 Binaries that are 64 bytes or less can be stored directly on the
 process heap as _heap binaries_. Larger binaries are reference
-counted and the paylod is stored outside of the process heap, a
+counted and the payload is stored outside of the process heap, a
 reference to the payload is stored on the process heap in an object
 called a _ProcBin_.