From: Matthijs Kooijman Date: Tue, 8 Dec 2009 20:45:27 +0000 (+0100) Subject: Fix references. X-Git-Tag: final-thesis~18 X-Git-Url: https://git.stderr.nl/gitweb?p=matthijs%2Fmaster-project%2Freport.git;a=commitdiff_plain;h=28b745e6faf774843ecdfbce67bdd22b8b4fc550 Fix references. --- diff --git a/Chapters/HardwareDescription.tex b/Chapters/HardwareDescription.tex index f5e2615..f1bf5af 100644 --- a/Chapters/HardwareDescription.tex +++ b/Chapters/HardwareDescription.tex @@ -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 diff --git a/Chapters/Normalization.tex b/Chapters/Normalization.tex index 0b5bc60..77dd977 100644 --- a/Chapters/Normalization.tex +++ b/Chapters/Normalization.tex @@ -797,7 +797,6 @@ 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. @@ -1079,7 +1078,7 @@ \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 @@ -1587,10 +1586,12 @@ \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 @@ -1718,7 +1719,7 @@ 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 @@ -2414,7 +2415,7 @@ 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] diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex index 8f94251..ff24bb0 100644 --- a/Chapters/Prototype.tex +++ b/Chapters/Prototype.tex @@ -678,6 +678,7 @@ support. \placeintermezzo{}{ + \defref{id function} \startframedtext[width=8cm,background=box,frame=no] \startalignment[center] {\tfa The \hs{id} function} @@ -795,7 +796,7 @@ 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.