Use normal style zeroes instead of using the sans font.
[matthijs/master-project/report.git] / Chapters / Introduction.tex
index f88b2257affdd9b5167b45e33edd60e33fd1c88d..334b1c89d734486f1f960bb92717f767b43c5a8c 100644 (file)
@@ -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.
@@ -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,11 +214,11 @@ 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
   reasons for choosing these languages are detailed in section
@@ -240,7 +248,7 @@ 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.