X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=blobdiff_plain;f=Chapters%2FFuture.tex;h=9c7bb51ec5cdfe2b1444d2d9aed1f182b942a1df;hp=0399db9ba6d993ee7a76aa98f94cc3132c022d2a;hb=313351372e8c609c2875902d9c9a2b89f7c97032;hpb=747c2ba3d485fb5c3543e9435fbd3dff59ddb3f8

diff --git a/Chapters/Future.tex b/Chapters/Future.tex
index 0399db9..9c7bb51 100644
--- a/Chapters/Future.tex
+++ b/Chapters/Future.tex
@@ -123,7 +123,7 @@ these descriptions without any special magic (though perhaps it should
 always inline the binding operators to reveal the flow of values).
 
 This highlights an important aspect of using a functional language for our
-descriptions: We can use the language itself to provide abstractions of common
+descriptions: we can use the language itself to provide abstractions of common
 patterns, making our code smaller and easier to read.
 
 \subsection{Breaking out of the Monad}
@@ -234,7 +234,7 @@ feasible.
 
 \subsection{Arrows}
 Another abstraction mechanism offered by Haskell are arrows. Arrows are
-a generalisation of monads \cite[hughes98], for which \GHC also supports
+a generalisation of monads \cite[hughes98], for which \GHC\ also supports
 some syntax sugar \cite[paterson01]. Their use for hiding away state
 boilerplate is not directly evident, but since arrows are a complex
 concept further investigation is appropriate.
@@ -477,9 +477,9 @@ while still allowing simple functions without any extra overhead when complex
 behaviour is not needed.
 
 The main cost of this approach will probably be extra complexity in the
-compiler: The paths (state) data can take become very non-trivial, and it
+compiler: the paths (state) data can take become very non-trivial, and it
 is probably hard to properly analyze these paths and produce the
-intended \VHDL description.
+intended \VHDL\ description.
 
 \section{Multiple cycle descriptions}
 In the current Cλash prototype, every description is a single-cycle
@@ -523,7 +523,7 @@ generates just a single element each cycle).
 Naively, this matching could be done using a (built-in) function with a
 signature like \lam{[a] -> a}, which also serves as an indicator to the
 compiler that some expanding over time is required. However, this poses a
-problem for simulation: How will our Haskell implementation of this magical
+problem for simulation: how will our Haskell implementation of this magical
 built-in function know which element of the input list to return. This
 obviously depends on the current cycle number, but there is no way for this
 function to know the current cycle without breaking all kinds of safety and
@@ -587,7 +587,7 @@ higher-order value at the spot where it is applied, and thus the higher-order
 value disappears.
 
 This approach is commonly known as the \quote{Reynolds approach to
-defuntionalization}, first described by J.C. Reynolds \cite[reynolds98] and
+defuntionalization}, first described by J.C. Reynolds \cite[reynolds98]\ and
 seems to apply well to this situation. One note here is that Reynolds'
 approach puts all the higher-order values in a single datatype. For a typed
 language, we will at least have to have a single datatype for each function
@@ -597,7 +597,7 @@ that is never used for a particular state variable. This separation is
 probably a non-trivial problem, though.
 
 \section{Don't care values}
-  A powerful value in \VHDL is the \emph{don't care} value, given as
+  A powerful value in \VHDL\ is the \emph{don't care} value, given as
   \type{'-'}. This value tells the compiler that you do not really care about
   which value is assigned to a signal, allowing the compiler to make some
   optimizations. Since choice in hardware is often implemented using
@@ -622,7 +622,7 @@ probably a non-trivial problem, though.
     This would also require some kind of \quote{Don't careable} type class
     that allows each type to specify what its don't care value is. The
     compiler must then recognize this constant and replace it with don't care
-    values in the final \VHDL code.
+    values in the final \VHDL\ code.
 
     This is of course a very intrusive solution. Every type must become member
     of this type class, and there is now some member in every type that is a