+ 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).
+
+ 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
+ inverter instead of a multiplexer). However, we will try to make a
+ general translation, which works for all possible \hs{case} expressions.
+ Optimizations such as these are left for the \VHDL\ synthesizer, which
+ handles them very well.
+
+ \placeintermezzo{}{
+ \startframedtext[width=8cm,background=box,frame=no]
+ \startalignment[center]
+ {\tfa Arguments / results vs. inputs / outputs}
+ \stopalignment
+ \blank[medium]
+ Due to the translation chosen for function application, there is a
+ very strong relation between arguments, results, inputs and outputs.
+ For clarity, the former two will always refer to the arguments and
+ results in the functional description (either Haskell or Core). The
+ latter two will refer to input and output ports in the generated
+ \VHDL.
+
+ Even though these concepts seem to be nearly identical, when stateful
+ functions are introduces we will see arguments and results that will
+ not get translated into input and output ports, making this
+ distinction more important.
+ \stopframedtext
+ }
+
+ A slightly more complex (but very powerful) form of choice is pattern
+ matching. A function can be defined in multiple clauses, where each clause
+ 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
+ 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
+ nested) multiplexers. These multiplexers are driven by comparators and
+ other logic, that check each pattern in turn.