{\typebuffervhdl{And3VHDL}}
\placeintermezzo{}{
+ \defref{top level binding}
\defref{top level binder}
\defref{top level function}
\startframedtext[width=8cm,background=box,frame=no]
{\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.
+ 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:
simply be translated to a conditional assignment, where the conditions use
equality comparisons against the constructors in the \hs{case} expressions.
- In \in{example}[ex:CaseInv] a simple \hs{case} expression is shown,
- scrutinizing a boolean value. The corresponding architecture has a
- comparator to determine which of the constructors is on the \hs{in}
- input. There is a multiplexer to select the output signal. The two options
- for the output signals are just constants, but these could have been more
- complex expressions (in which case also both of them would be working in
- parallel, regardless of which output would be chosen eventually).
+ In \in{example}[ex:Inv] two versions of an inverter are shown. The first
+ uses a simple \hs{case} expression, scrutinizing a boolean value. The
+ corresponding architecture has a comparator to determine which of the
+ constructors is on the \hs{in} input. There is a multiplexer to select the
+ output signal (which is just a conditional assignment in the generated
+ \VHDL). The two options for the output signals are just constants,
+ but these could have been more complex expressions (in which case also
+ both of them would be working in parallel, regardless of which output
+ would be chosen eventually). The \VHDL\ generated for (both versions of)
+ this inverter is shown in \in{example}[ex:InvVHDL].
If we would translate a Boolean to a bit value, we could of course remove
the comparator and directly feed 'in' into the multiplexer (or even use an
specifies a pattern. When the arguments match the pattern, the
corresponding clause will be used.
- The architecture described by \in{example}[ex:PatternInv] is of course the
- same one as the one in \in{example}[ex:CaseInv]. The general interpretation
+ \in{Example}[ex:Inv] also shows an inverter that uses pattern matching.
+ The architecture it describes is of course the
+ same one as the description with a case expression. The general interpretation
of pattern matching is also similar to that of \hs{case} expressions: generate
hardware for each of the clauses (like each of the clauses of a \hs{case}
expression) and connect them to the function output through (a number of
% {\boxedgraphic{Inv}}{The architecture described by the Haskell description.}
% \stopcombination
% }
- \placeexample[][ex:InvVHDL]{\VHDL\ generated for \hs{inv} from \in{example}[ex:Inv]}
+ \placeexample[][ex:InvVHDL]{\VHDL\ generated for (both versions of) \hs{inv} from \in{example}[ex:Inv]}
{\typebuffervhdl{InvVHDL}}
\section{Types}
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
projects / matthijs / master-project / report.git / blobdiff