Fix / remove some final todos.

[matthijs/master-project/report.git] / Chapters / Conclusions.tex

diff --git a/Chapters/Conclusions.tex b/Chapters/Conclusions.tex
index 7e76abc4eca6c5a79b28687dfbcae784af49e651..e53e300ae654034a36425137750a56a367f6518e 100644 (file)
--- a/Chapters/Conclusions.tex
+++ b/Chapters/Conclusions.tex
@@ -7,7 +7,7 @@ In this research, we have seen that a functional language is well suited
 for hardware descriptions. Function applications provide elegant notation for
 component instantiation and the various choice mechanisms (pattern matching,
 case expressions, if expressions) are well suited to describe conditional
-assigment in the hardware.
+assignment in the hardware.
 
 Useful features from the functional perspective, like polymorphism and
 higher-order functions and expressions also prove suitable to describe
@@ -36,7 +36,7 @@ support for more advanced dependent types (and even type level operations) as
 a fundamental part of the language. The need for dependent typing is
 particularly present in Cλash to be able to fix some properties (list length,
 recursion depth, etc.) at compile time. Having better support for dependent
-typing might allow the use of typesafe recursion in Cλash, though this is
+typing might allow the use of type-safe recursion in Cλash, though this is
 fundamentally still a hard problem.
 
 The choice of describing state very explicitly as extra arguments and
@@ -48,13 +48,13 @@ state can be handled just like other arguments and results.
 On the other hand, the explicitness of the states and in particular
 substates, mean that more complex descriptions can become cumbersome
 very quickly. One finds that dealing with unpacking, passing, receiving
-and repacking becomes tedious and even errorprone. Removing some of this
+and repacking becomes tedious and even error-prone. Removing some of this
 boilerplate would make the language even easier to use.
 
 On the whole, the usefulness of Cλash for describing hardware is not
 completely clear yet. Most elements of the language have proven
-suitable, and even a real world hardware circuit (the reducer \todo{ref
-christiaan}) has been implemented. However, the language has not been
+suitable, and even a real world hardware circuit (a reducer circuit
+\cite[baaij09]) has been implemented. However, the language has not been
 used during a complete design process, where its rapid prototyping and
 reusability qualities could become real advantages, or perhaps the state
 boilerplate or synchronicity limitations could become real problems.
@@ -63,10 +63,10 @@ It is expected that Cλash will be used as a tool in education at the
 University of Twente soon. Hopefully this will provide a better insight
 in how the system performs.
 
-The prototype compiler has a clear design. Its frontend is taken from the \GHC\
+The prototype compiler has a clear design. Its front-end is taken from the \GHC\
 compiler and desugars Haskell into a small, but functional and typed
 language, called \emph{Core}. Cλash adds a transformation system that reduces
-this small language to a normal form and a simple backend that performs a
+this small language to a normal form and a simple back-end that performs a
 direct translation to \VHDL. This approach has worked well and should probably
 be preserved. Especially the transformation based normalization system is
 suitable. It is easy to implement a transformation in the prototype, though it