Remove lambda abstraction rule from part 10 of compiler series.

content/blog/10_compiler_polymorphism.md

@@ -67,11 +67,6 @@ Rule|Name and Description
     {\Gamma \vdash e_1 \; e_2 : \tau_2}
 {{< /latex >}}| __App__: If an expression \\(e\_1\\), which is a function from monomorphic type \\(\\tau\_1\\) to another monomorphic type \\(\\tau\_2\\), is applied to an argument \\(e\_2\\) of type \\(\\tau\_1\\), then the result is of type \\(\\tau\_2\\).
 {{< latex >}}
-\frac
-    {\Gamma, x:\tau \vdash e : \tau'}
-    {\Gamma \vdash \lambda x.e : \tau \rightarrow \tau'}
-{{< /latex >}}| __Abs__: If the body \\(e\\) of a lambda abstraction \\(\\lambda x.e\\) is of type \\(\\tau\'\\) when \\(x\\) is of type \\(\\tau\\) then the whole lambda abstraction is of type \\(\\tau \\rightarrow \\tau\'\\).
-{{< latex >}}
 \frac
     {\Gamma \vdash e : \tau \quad \text{matcht}(\tau, p_i) = b_i
         \quad \Gamma,b_i \vdash e_i : \tau_c}
@@ -111,5 +106,6 @@ for all possible \\(a\\)". This new expression using "forall" is what we call a
 For simplicity, we only allow "forall" to be at the front of a polytype. That is, expressions like
 \\(a \\rightarrow \\forall b \\; . \\; b \\rightarrow b\\) are not valid polytypes as far as we're concerned.
 
-It's key to observe that the majority of the typing rules in the above table use monotypes (\\(\\tau\\)). Only
-two rules seem to mention \\(\\sigma\\): __Inst__ and __Gen__.
+It's key to observe that only some of the typing rules in the above table use monotypes (\\(\\tau\\)). Whereas expressions
+consisting of a single variable can be polymorphically typed, this is not true for function applications and case expressions.
+In fact, according to our rules, there is no way to introduce a polytype anywhere into our system!