X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FIntroduction.tex;h=18950802c16f31fd2f6f33036e7076218389c436;hp=f88b2257affdd9b5167b45e33edd60e33fd1c88d;hb=f2d45a8c05c4fff4eb9574e8514b213fbfc8fb84;hpb=492b0d8d81c104b4b85fd1963a9d4a8b53f00e92

diff --git a/Chapters/Introduction.tex b/Chapters/Introduction.tex
index f88b225..1895080 100644
--- a/Chapters/Introduction.tex
+++ b/Chapters/Introduction.tex
@@ -1,21 +1,28 @@
 \chapter[chap:introduction]{Introduction}
 This thesis describes the result and process of my work during my
-Master's assignment. In these pages, I will try to introduce the world
+Master's assignment. In these pages, I will introduce the world
 of hardware descriptions, the world of functional languages and
 compilers and introduce the hardware description language Cλash that will
 connect these worlds and puts a step towards making hardware programming
 on the whole easier, more maintainable and generally more pleasant.
 
+This assignment has been performed in close cooperation with Christiaan
+Baaij, whose Master's thesis \cite[baaij09]\ has been completed at the
+same time as this thesis. Where this thesis focuses on the
+interpretation of the Haskell language and the compilation process,
+\cite[baaij09]\ has a more thorough study of the field, explores more
+advanced types and provides a case study.
+
 % Use \subject to hide this section from the toc
 \subject{Research goals}
   This research started out with the notion that a functional program is very
   easy to interpret as a hardware description. A functional program typically
-  does no assumptions about evaluation order and does not have any side
+  makes no assumptions about evaluation order and does not have any side
   effects. This fits hardware nicely, since the evaluation order for hardware
   is simply everything in parallel.
 
   As a motivating example, consider the simple functional program shown in
-  \in{example}[ex:AndWord]\footnote[notfinalsyntax]{Note that this example is not in the final
+  \in{example}[ex:AndWord]\footnote[notfinalsyntax]{This example is not in the final
   Cλash syntax}. This is a very natural way to describe a lot of parallel not
   ports, that perform a bitwise not on a bitvector. The example also shows an
   image of the architecture described.
@@ -58,14 +65,14 @@ on the whole easier, more maintainable and generally more pleasant.
     % Draw a dotted line between the middle operations
     ncline(a2)(a3) "linestyle(dashed withdots)", "arrows(-)";
   \stopuseMPgraphic
-  \placeexample[here][ex:AndWord]{Simple architecture that inverts a vector of bits.}
+  \placeexample[][ex:AndWord]{Simple architecture that inverts a vector of bits.}
     \startcombination[2*1]
       {\typebufferlam{AndWord}}{Haskell description of the architecture.}
       {\boxedgraphic{AndWord}}{The architecture described by the Haskell description.}
     \stopcombination
 
   Slightly more complicated is the incremental summation of
-  values show in \in{example}[ex:RecursiveSum]\note[notfinalsyntax].
+  values shown in \in{example}[ex:RecursiveSum]\note[notfinalsyntax].
 
   In this example we see a recursive function \hs{sum'} that recurses over a
   list and takes an accumulator argument that stores the sum so far. On each
@@ -140,7 +147,8 @@ on the whole easier, more maintainable and generally more pleasant.
 
 
   Or... is this the description of a single accumulating adder, that will add
-  one element of each input each clock cycle and has a reset value of 0? In
+  one element of each input each clock cycle and has a reset value of
+  {\definedfont[Serif*normalnum]0}? In
   that case, we would have described the architecture show in \in{example}[ex:RecursiveSumAlt]
 
   \startuseMPgraphic{RecursiveSumAlt}
@@ -206,13 +214,13 @@ on the whole easier, more maintainable and generally more pleasant.
   \startitemize
     \item How to interpret recursion in descriptions?
     \item How to interpret polymorphism?
-    \item How to interpret higher order descriptions?
+    \item How to interpret higher-order descriptions?
   \stopitemize
 
   In addition to looking at designing a hardware description language, we
-  will also implement a prototype to test drive our ideas. This prototype will
+  will also implement a prototype to test ideas. This prototype will
   translate hardware descriptions written in the Haskell functional language
-  to simple (netlist-like) hardware descriptions in the \VHDL language. The
+  to simple (netlist-like) hardware descriptions in the \VHDL\ language. The
   reasons for choosing these languages are detailed in section
   \in{}[sec:prototype:input] and \in{}[sec:prototype:output] respectively.
 
@@ -228,6 +236,8 @@ on the whole easier, more maintainable and generally more pleasant.
     Systems). The lambda in the name is of course a reference to the
     lambda abstraction, which is an essential element of most functional
     languages (and is also prominent in the Haskell logo).
+
+    Cλash is pronounced like \quote{Clash}.
     \stopframedtext
   }
 
@@ -240,11 +250,11 @@ on the whole easier, more maintainable and generally more pleasant.
 In the first chapter, we will sketch the context for this research.
 The current state and history of hardware description languages will be
 briefly discussed, as well as the state and history of functional
-programming. Since we're not the first to have merged these approaches,
+programming. Since we are not the first to have merged these approaches,
 a number of other functional hardware description languages are briefly
 described.
 
-Chapter two describes the exploratory part of this research: How can we
+Chapter two describes the exploratory part of this research: how can we
 describe hardware using a functional language and how can we use functional
 concepts for hardware descriptions?