Add section on polymorphism.
[matthijs/master-project/dsd-paper.git] / cλash.lhs
index f7a763ee1923d1cbe5fd0d2775bc1e8d1a76dc50..5819c83dd48d7da7398a0c20748dd62278d876d2 100644 (file)
 % *** GRAPHICS RELATED PACKAGES ***
 %
 \ifCLASSINFOpdf
-  \usepackage[pdftex]{graphicx}
+  \usepackage[pdftex]{graphicx}
   % declare the path(s) where your graphic files are
   % \graphicspath{{../pdf/}{../jpeg/}}
   % and their extensions so you won't have to specify these with
@@ -512,15 +512,15 @@ in this research. The functions describe the behavior of the hardware between
 clock cycles, as such, only synchronous systems can be described. Many 
 functional hardware description models signals as a stream of all values over 
 time; state is then modeled as a delay on this stream of values. The approach 
-taken in this research is to make the current state of the circuit part of the 
-input of the function and the updated state part of the output of a function.
+taken in this research is to make the current state of a circuit part of the 
+input of the function and the updated state part of the output.
 
 Like the standard hardware description languages, descriptions made in a 
 functional hardware description language must eventually be converted into a 
 netlist. This research also features a prototype translator called \CLaSH\ 
 (pronounced: clash), which converts the Haskell code to equivalently behaving 
 synthesizable \VHDL\ code, ready to be converted to an actual netlist format 
-by optimizing \VHDL\ synthesis tools.
+by an optimizing \VHDL\ synthesis tools.
 
 \section{Hardware description in Haskell}
 
@@ -533,14 +533,14 @@ by optimizing \VHDL\ synthesis tools.
     as a tuple), so having just a single output port does not create a
     limitation.
 
-    Each function application in turn becomes component instantiation.
+    Each function application in turn becomes component instantiation.
     Here, the result of each argument expression is assigned to a
     signal, which is mapped to the corresponding input port. The output
     port of the function is also mapped to a signal, which is used as
     the result of the application itself.
 
     Since every top level function generates its own component, the
-    hierarchy of of function calls is reflected in the final \VHDL\
+    hierarchy of function calls is reflected in the final \VHDL\
     output as well, creating a hierarchical \VHDL\ description of the
     hardware.  This separation in different components makes the
     resulting \VHDL\ output easier to read and debug.
@@ -552,7 +552,17 @@ by optimizing \VHDL\ synthesis tools.
 mac a b c = add (mul a b) c
 \end{code}
 
-\comment{TODO: Pretty picture}
+\begin{figure}
+\centerline{\includegraphics{mac}}
+\caption{Combinatorial Multiply-Accumulate (curried)}
+\label{img:mac-comb}
+\end{figure}
+
+\begin{figure}
+\centerline{\includegraphics{mac-nocurry}}
+\caption{Combinatorial Multiply-Accumulate (uncurried)}
+\label{img:mac-comb-nocurry}
+\end{figure}
 
   \subsection{Choices}
     Although describing components and connections allows describing a
@@ -740,6 +750,66 @@ data IntPair = IntPair Int Int
         currently supported.
     \end{xlist}
 
+  \subsection{Polymorphic functions}
+    A powerful construct in most functional language is polymorphism.
+    This means the arguments of a function (and consequentially, values
+    within the function as well) do not need to have a fixed type.
+    Haskell supports \emph{parametric polymorphism}, meaning a
+    function's type can be parameterized with another type.
+
+    As an example of a polymorphic function, consider the following
+    \hs{append} function's type:
+    
+    TODO: Use vectors instead of lists?
+
+    \begin{code}
+    append :: [a] -> a -> [a]
+    \end{code}
+
+    This type is parameterized by \hs{a}, which can contain any type at
+    all. This means that append can append an element to a list,
+    regardless of the type of the elements in the list (but the element
+    added must match the elements in the list, since there is only one
+    \hs{a}).
+
+    This kind of polymorphism is extremely useful in hardware designs to
+    make operations work on a vector without knowing exactly what elements
+    are inside, routing signals without knowing exactly what kinds of
+    signals these are, or working with a vector without knowing exactly
+    how long it is. Polymorphism also plays an important role in most
+    higher order functions, as we will see in the next section.
+
+    The previous example showed unconstrained polymorphism (TODO: How is
+    this really called?): \hs{a} can have \emph{any} type. Furthermore,
+    Haskell supports limiting the types of a type parameter to specific
+    class of types. An example of such a type class is the \hs{Num}
+    class, which contains all of Haskell's numerical types.
+
+    Now, take the addition operator, which has the following type:
+
+    \begin{code}
+    (+) :: Num a => a -> a -> 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}.
+    Our numerical built-in types are also instances of the \hs{Num}
+    class, so we can use the addition operator on \hs{SizedWords} as
+    well as on {SizedInts}.
+
+    In \CLaSH, unconstrained polymorphism is completely supported. Any
+    function defined can have any number of unconstrained type
+    parameters. The \CLaSH compiler will infer the type of every such
+    argument depending on how the function is applied. There is one
+    exception to this: The top level function that is translated, can
+    not have any polymorphic arguments (since it is never applied, so
+    there is no way to find out the actual types for the type
+    parameters).
+
+    \CLaSH does not support user-defined type classes, but does use some
+    of the builtin ones for its builtin functions (like \hs{Num} and
+    \hs{Eq}).
+
   \subsection{State}
     A very important concept in hardware it the concept of state. In a 
     stateful design, the outputs depend on the history of the inputs, or the