Fix references.
authorMatthijs Kooijman <matthijs@stdin.nl>
Tue, 8 Dec 2009 20:45:27 +0000 (21:45 +0100)
committerMatthijs Kooijman <matthijs@stdin.nl>
Tue, 8 Dec 2009 20:45:27 +0000 (21:45 +0100)
Chapters/HardwareDescription.tex
Chapters/Normalization.tex
Chapters/Prototype.tex

index f5e2615..f1bf5af 100644 (file)
@@ -138,6 +138,7 @@ and3 a b c = and (and a b) c
       {\typebuffervhdl{And3VHDL}}
 
   \placeintermezzo{}{
+    \defref{top level binding}
     \defref{top level binder}
     \defref{top level function}
     \startframedtext[width=8cm,background=box,frame=no]
@@ -145,15 +146,18 @@ and3 a b c = and (and a b) c
       {\tfa Top level binders and functions}
     \stopalignment
     \blank[medium]
-      A top level binder is any binder (variable) that is declared in
-      the \quote{global} scope of a Haskell program (as opposed to a
-      binder that is bound inside a function.
+      A \emph{top level binder} is any binder (variable) that is
+      declared in the \quote{global} scope of a Haskell program (as
+      opposed to a binder that is bound inside a function. The binder
+      together with its body is referred to as a \emph{top level
+      binding}.
 
       In Haskell, there is no sharp distinction between a variable and a
       function: a function is just a variable (binder) with a function
-      type. This means that a top level function is just any top level
-      binder with a function type. This also means that sometimes top level
-      function will be used when top level binder is really meant.
+      type. This means that a \emph{top level function} is just any top
+      level binder with a function type. This also means that sometimes
+      top level function will be used when top level binder is really
+      meant.
 
       As an example, consider the following Haskell snippet:
 
@@ -1015,9 +1019,8 @@ acc in s = (s', out)
 
         This is the major downside of this approach: the separation between
         interface and implementation is limited. However, since Cλash is not
-        very suitable for separate compilation (see
-        \in{section}[sec:prototype:separate]) this is not a big problem in
-        practice.
+        very suitable for separate compilation this is not a big problem
+        in practice.
 
         Additionally, when using a type synonym for the state type
         of each function, we can still provide explicit type signatures
index 0b5bc60..77dd977 100644 (file)
       unique. This is done by generating a fresh binder for every binder used. This
       also replaces binders that did not cause any conflict, but it does ensure that
       all binders within the function are generated by the same unique supply.
-      \refdef{fresh binder}
       \item Whenever a new binder must be generated, we generate a fresh binder that
       is guaranteed to be different from \emph{all binders generated so far}. This
       can thus never introduce duplication and will maintain the invariant.
         \in{Example}[ex:trans:toplevelinline] shows a typical application of
         the addition operator generated by \GHC. The type and dictionary
         arguments used here are described in
-        \in{Section}[section:prototype:polymorphism].
+        \in{Section}[sec:prototype:coretypes].
 
         Without this transformation, there would be a \lam{(+)} entity
         in the \VHDL\ which would just add its inputs. This generates a
 
         \startitemize
         \item An extractor case with a single alternative that picks a field
-        from a datatype, \eg\ \lam{case x of (a, b) -> a}.
+        from a datatype, \eg\ \lam{case x of (a, b) ->
+        a}.\defref{extractor case}
         \item A selector case with multiple alternatives and only wild binders, that
         makes a choice between expressions based on the constructor of another
-        expression, \eg\ \lam{case x of Low -> a; High -> b}.
+        expression, \eg\ \lam{case x of Low -> a; High ->
+        b}.\defref{selector case}
         \stopitemize
 
         For an arbitrary case, that has \lam{n} alternatives, with
       actual transformations.
 
       \subsubsection{Removing Polymorphism}
-        As noted in \in{section}[sec:prototype:polymporphism],
+        As noted in \in{section}[sec:prototype:coretypes],
         polymorphism is made explicit in Core through type and
         dictionary arguments. To remove the polymorphism from a
         function, we can simply specialize the polymorphic function for
       outgoing edges (meaning no transformation applies to it). The set of
       nodes without outgoing edges is called the \emph{normal set}. Similarly,
       the set of nodes containing expressions in intended normal form
-      \refdef{intended normal form} is called the \emph{intended normal set}.
+      \refdef{intended normal form definition} is called the \emph{intended normal set}.
 
       From such a graph, we can derive some properties easily:
       \startitemize[KR]
index 8f94251..ff24bb0 100644 (file)
       support.
 
       \placeintermezzo{}{
+        \defref{id function}
         \startframedtext[width=8cm,background=box,frame=no]
         \startalignment[center]
           {\tfa The \hs{id} function}
         A predicate type introduces a constraint on a type variable introduced
         by a forall type (or type lambda). In the example above, the type
         variable \lam{t} can only contain types that are an \emph{instance} of
-        the \emph{type class} \lam{Show}. \refdef{type class}
+        the \emph{type class} \lam{Show}.
 
         There are other sorts of predicate types, used for the type families
         extension, which we will not discuss here.