Fix references.
[matthijs/master-project/report.git] / Chapters / HardwareDescription.tex
index f5e2615a5b404e17920cd3779e88539df9db4be9..f1bf5af2a741456ab7136c55e20c8c418b499f99 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