Fix some more spelling and sentence mistakes

diff --git a/cλash.lhs b/cλash.lhs
index 8ab7336b1bb8f0744ea83e5540272d040d5d0608..abfb737598245c5c2af7e1756c31d14e4ac83f26 100644 (file)
--- a/cλash.lhs
+++ b/cλash.lhs
@@ -688,8 +688,8 @@ eventual netlist representation is also highlighted.
 
     The naive netlist corresponding to both versions of the example is 
     depicted in \Cref{img:choice}. Note that the \hs{pred} variable is only
 
     The naive netlist corresponding to both versions of the example is 
     depicted in \Cref{img:choice}. Note that the \hs{pred} variable is only

-    compared to \hs{Equal}, as an inequality immediately implies that the 
-    \hs{pred} variable is \hs{NotEqual}.
+    compared to \hs{Equal}, as an inequality immediately implies that 
+    \hs{pred} is \hs{NotEqual}.

 
     \hspace{-1.7em}
     \begin{minipage}{0.93\linewidth}
 
     \hspace{-1.7em}
     \begin{minipage}{0.93\linewidth}


@@ -781,14 +781,14 @@ eventual netlist representation is also highlighted.
     \emph{built-in} types and \emph{user-defined} types. Built-in types are 
     those types for which a fixed translation is defined within the \CLaSH\ 
     compiler. The \CLaSH\ compiler has generic translation rules to
     \emph{built-in} types and \emph{user-defined} types. Built-in types are 
     those types for which a fixed translation is defined within the \CLaSH\ 
     compiler. The \CLaSH\ compiler has generic translation rules to

-    translate the user-defined types described later on.
+    translate the user-defined types, which are described later on.

 
     The \CLaSH\ compiler is able to infer unspecified (polymorphic) types,
     meaning that a developer does not have to annotate every function with a 
     type signature. % (even if it is good practice to do so).
     Given that the top-level entity of a circuit design is annotated with 
 
     The \CLaSH\ compiler is able to infer unspecified (polymorphic) types,
     meaning that a developer does not have to annotate every function with a 
     type signature. % (even if it is good practice to do so).
     Given that the top-level entity of a circuit design is annotated with 

-    concrete types, the \CLaSH\ compiler can specialize polymorphic functions 
-    to functions with concrete types.
+    concrete/monomorphic types, the \CLaSH\ compiler can specialize 
+    polymorphic functions to functions with concrete types.

   
     % Translation of two most basic functional concepts has been
     % discussed: function application and choice. Before looking further
   
     % Translation of two most basic functional concepts has been
     % discussed: function application and choice. Before looking further


@@ -840,7 +840,7 @@ eventual netlist representation is also highlighted.
         % \texttt{signed} respectively.
       \item[\bf{Vector}]
         this is a vector type that can contain elements of any other type and
         % \texttt{signed} respectively.
       \item[\bf{Vector}]
         this is a vector type that can contain elements of any other type and

-        has a fixed length. The \hs{Vector} type constructor takes two type 
+        has a static length. The \hs{Vector} type constructor takes two type 

         arguments: the length of the vector and the type of the elements 
         contained in it. The short-hand notation used for the vector type in  
         the rest of paper is: \hs{[a|n]}, where \hs{a} is the element 
         arguments: the length of the vector and the type of the elements 
         contained in it. The short-hand notation used for the vector type in  
         the rest of paper is: \hs{[a|n]}, where \hs{a} is the element 


@@ -978,17 +978,18 @@ eventual netlist representation is also highlighted.
     variable can only be instantiated to a type whose members supports the 
     overloaded functions associated with the type class. 
     
     variable can only be instantiated to a type whose members supports the 
     overloaded functions associated with the type class. 
     

-    As an example we will take a look at type signature of the function 
-    \hs{sum}, which sums the values in a vector:
+    An example of a type signature that includes such a constraint if the 
+    signature of the \hs{sum} function, which sums the values in a vector:

     \begin{code}
     sum :: Num a => [a|n] -> a
     \end{code}
 
     This type is again parameterized by \hs{a}, but it can only contain
     types that are \emph{instances} of the \emph{type class} \hs{Num}, so that  
     \begin{code}
     sum :: Num a => [a|n] -> a
     \end{code}
 
     This type is again parameterized by \hs{a}, but it can only contain
     types that are \emph{instances} of the \emph{type class} \hs{Num}, so that  

-    we know that the addition (+) operator is defined for that type. 
-    \CLaSH's built-in numerical types are also instances of the \hs{Num}
-    class. 
+    the compiler knows that the addition (+) operator is defined for that 
+    type. 
+    % \CLaSH's built-in numerical types are also instances of the \hs{Num} 
+    % class. 

     % so we can use the addition operator (and thus the \hs{sum}
     % function) with \hs{Signed} as well as with \hs{Unsigned}.
 
     % so we can use the addition operator (and thus the \hs{sum}
     % function) with \hs{Signed} as well as with \hs{Unsigned}.
 


@@ -998,12 +999,14 @@ eventual netlist representation is also highlighted.
     instances. The \CLaSH\ compiler will infer the type of every polymorphic 
     argument depending on how the function is applied. There is however one 
     constraint: the top level function that is being translated can not have 
     instances. The \CLaSH\ compiler will infer the type of every polymorphic 
     argument depending on how the function is applied. There is however one 
     constraint: the top level function that is being translated can not have 

-    any polymorphic arguments. The arguments can not be polymorphic as the 
-    function is never applied and consequently there is no way to determine 
-    the actual types for the type parameters. The members of some standard 
-    Haskell type classes are supported as built-in functions, including: 
-    \hs{Num} for numerical operations, \hs{Eq} for the equality operators, and 
-    \hs{Ord} for the comparison/order operators.
+    any polymorphic arguments. The arguments of the top-level can not be 
+    polymorphic as the function is never applied and consequently there is no 
+    way to determine the actual types for the type parameters. 
+    
+    With regard to the built-in types, it should be noted that members of 
+    some of the standard Haskell type classes are supported as built-in 
+    functions. These include: the numerial operators of \hs{Num}, the equality 
+    operators of \hs{Eq}, and the comparison/order operators of \hs{Ord}.

 
   \subsection{Higher-order functions \& values}
     Another powerful abstraction mechanism in functional languages, is
 
   \subsection{Higher-order functions \& values}
     Another powerful abstraction mechanism in functional languages, is


@@ -1084,13 +1087,12 @@ eventual netlist representation is also highlighted.
       \end{example}
     \end{minipage}
 
       \end{example}
     \end{minipage}
 

-    Finally, not only built-in functions can have higher order
-    arguments, but any function defined in \CLaSH\ may have functions as
-    arguments. This allows the hardware designer to use a powerful
-    abstraction mechanism in his designs and have an optimal amount of
-    code reuse. The only exception is again the top-level function: if a 
-    function-typed argument is not applied with an actual function, no 
-    hardware can be generated.    
+    Finally, not only built-in functions can have higher order arguments (such 
+    as the \hs{map} function), but any function defined in \CLaSH\ may have 
+    functions as arguments. This allows the circuit designer to use a 
+    powerful amount of code reuse. The only exception is again the top-level 
+    function: if a function-typed argument is not applied with an actual 
+    function, no hardware can be generated.    

 
     % \comment{TODO: Describe ALU example (no code)}
 
 
     % \comment{TODO: Describe ALU example (no code)}