X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Core2Core.tex;h=f576b7196e71b52f6e51fcd2fbb57efd24ba042e;hp=437aae70425fbc87c8cdbe9b5b9a1c8215d938b5;hb=f326a373622a675fea4bc86284b75d866e2ef4cf;hpb=8e496c475d663131ad09c62dc5a3efe30e3f2e15

diff --git a/Core2Core.tex b/Core2Core.tex
index 437aae7..f576b71 100644
--- a/Core2Core.tex
+++ b/Core2Core.tex
@@ -63,7 +63,7 @@ Matthijs Kooijman
 \section{Introduction}
 As a new approach to translating Core to VHDL, we investigate a number of
 transformations on our Core program, which should bring the program into a
-well-defined "canonical" state, which is subsequently trivial to translate to
+well-defined "canonical" form, which is subsequently trivial to translate to
 VHDL.
 
 The transformations as presented here are far from complete, but are meant as
@@ -73,16 +73,16 @@ apparent from the end result, there will be additional transformations needed
 to fully reach our goal, and some transformations must be applied more than
 once. How exactly to (efficiently) do this, has not been investigated.
 
-Lastly, I hope to be able to state a number of pre- and postconditinos for
+Lastly, I hope to be able to state a number of pre- and postconditions for
 each transformation. If these can be proven for each transformation, and it
-can be shown that ther exists some ordering of transformations for which the
+can be shown that there exists some ordering of transformations for which the
 postcondition implies the canonical form, we can show that the transformations
 do indeed transform any program (probably satisfying a number of
 preconditions) to the canonical form.
 
 \section{Goal}
 The transformations described here have a well-defined goal: To bring the
-program in a well-defined program that is directly translatable to hardware,
+program in a well-defined form that is directly translatable to hardware,
 while fully preserving the semantics of the program.
 
 This {\em canonical form} is again a Core program, but with a very specific
@@ -214,14 +214,14 @@ canonical form.
     in
       case s of
         (a, b) ->
-          r = case a of
-                High -> add
-                Low -> let
-                  op' = case b of
-                    High -> sub
-                    Low  -> \c d -> c
-                  in
-                    \c d -> op' d c
+          case a of
+            High -> add
+            Low -> let
+              op' = case b of
+                High -> sub
+                Low  -> \c d -> c
+              in
+                \c d -> op' d c
 \stoptyping
 
 \subsection{Argument extraction}
@@ -396,7 +396,7 @@ As noted before, the above transformations are not complete. Other needed
 transformations include:
 \startitemize
 \item Inlining of local identifiers with a function type. Since these cannot
-be represented in hardware directly, they must be transformated into something
+be represented in hardware directly, they must be transformed into something
 else. Inlining them should always be possible without loss of semantics (TODO:
 How true is this?) and can expose new possibilities for other transformations
 passes (such as application propagation when inlining {\tt j} above).