X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FNormalization.tex;fp=Chapters%2FNormalization.tex;h=1d65f4a4373adbce010df3e9f293bf01ca8ddcc6;hp=a811bfef339e1d613fc6aa25496ab68c92a3ef61;hb=14ba857230ddd3bed3e9fbdde81ad2f693488493;hpb=391f3ab5a3e21567b1b1b62b1c7ed47fcdb40886

diff --git a/Chapters/Normalization.tex b/Chapters/Normalization.tex
index a811bfe..1d65f4a 100644
--- a/Chapters/Normalization.tex
+++ b/Chapters/Normalization.tex
@@ -21,12 +21,12 @@
     \stopcombination
   }
 
-  The first step in the core to \small{VHDL} translation process, is normalization. We
-  aim to bring the core description into a simpler form, which we can
+  The first step in the Core to \small{VHDL} translation process, is normalization. We
+  aim to bring the Core description into a simpler form, which we can
   subsequently translate into \small{VHDL} easily. This normal form is needed because
-  the full core language is more expressive than \small{VHDL} in some
+  the full Core language is more expressive than \small{VHDL} in some
   areas (higher-order expressions, limited polymorphism using type
-  classes, etc.) and because core can describe expressions that do not
+  classes, etc.) and because Core can describe expressions that do not
   have a direct hardware interpretation.
 
   \section{Normal form}
@@ -320,7 +320,7 @@
       Now we have some intuition for the normal form, we can describe how we want
       the normal form to look like in a slightly more formal manner. The
       EBNF-like description in \in{definition}[def:IntendedNormal] captures
-      most of the intended structure (and generates a subset of \GHC's core
+      most of the intended structure (and generates a subset of \GHC's Core
       format). 
       
       There are two things missing from this definition: cast expressions are
@@ -712,7 +712,7 @@
     \subsection[sec:normalization:uniq]{Binder uniqueness}
       A common problem in transformation systems, is binder uniqueness. When not
       considering this problem, it is easy to create transformations that mix up
-      bindings and cause name collisions. Take for example, the following core
+      bindings and cause name collisions. Take for example, the following Core
       expression:
 
       \startlambda
@@ -1430,7 +1430,7 @@
         function type. Since these can be any expression, there is no
         transformation needed. Note that this category is exactly all
         expressions that are not transformed by the transformations for the
-        previous two categories. This means that \emph{any} core expression
+        previous two categories. This means that \emph{any} Core expression
         that is used as an argument to a built-in function will be either
         transformed into one of the above categories, or end up in this
         categorie. In any case, the result is in normal form.
@@ -2255,7 +2255,7 @@
         there are probably expressions involving cast expressions that cannot
         be brought into intended normal form by this transformation system.
 
-        The uses of casts in the core system should be investigated more and
+        The uses of casts in the Core system should be investigated more and
         transformations will probably need updating to handle them in all
         cases.
 
@@ -2503,7 +2503,7 @@
       our compilation to \VHDL. The main difference seems to be that in
       hardware every expression is always evaluated, while in software
       it is only evaluated if needed, but it should be possible to
-      assign a meaning to core expressions that assumes neither.
+      assign a meaning to Core expressions that assumes neither.
       
       Since each of the transformations can be applied to any
       subexpression as well, there is a constraint on our meaning
@@ -2543,7 +2543,7 @@
       By systematically reviewing the entire Core language definition
       along with the intended normal form definition (both of which have
       a similar structure), it should be possible to identify all
-      possible (sets of) core expressions that are not in intended
+      possible (sets of) Core expressions that are not in intended
       normal form and identify a transformation that applies to it.
       
       This approach is especially useful for proving completeness of our