\section[sec:description:application]{Function application}
- \todo{Sidenote: Inputs vs arguments}
The basic syntactic elements of a functional program are functions and
function application. These have a single obvious \small{VHDL}
translation: Each top level function becomes a hardware component, where each
the condition is false.
This \hs{if} function would then essentially describe a multiplexer and
- allows us to describe any architecture that uses multiplexers. \fxnote{Are
- there other mechanisms of choice in hardware?}
+ allows us to describe any architecture that uses multiplexers.
However, to be able to describe our hardware in a more convenient way, we
also want to translate Haskell's choice mechanisms. The easiest of these
simply be translated to a conditional assignment, where the conditions use
equality comparisons against the constructors in the \hs{case} expressions.
- \todo{Assignment vs multiplexers}
+ \placeintermezzo{}{
+ \defref{substitution notation}
+ \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
+ }
In \in{example}[ex:CaseInv] a simple \hs{case} expression is shown,
scrutinizing a boolean value. The corresponding architecture has a
Optimizations such as these are left for the \VHDL\ synthesizer, which
handles them very well.
- \todo{Be more explicit about >2 alternatives}
-
\startbuffer[CaseInv]
inv :: Bool -> Bool
inv x = case x of
nested) multiplexers. These multiplexers are driven by comparators and
other logic, that check each pattern in turn.
+ In these examples we have seen only binary case expressions and pattern
+ matches (\ie, with two alternatives). In practice, case expressions can
+ choose between more than two values, resulting in a number of nested
+ multiplexers.
+
\section{Types}
Translation of two most basic functional concepts has been
discussed: Function application and choice. Before looking further
Note that the concept of \emph{state} is no more than having some way
to communicate a value from one cycle to the next. By introducing a
- \hs{delay} function, we can do exactly that: Delay (each value in) a
+ \hs{delay} function, we can do exactly that: delay (each value in) a
stream so that we can "look into" the past. This \hs{delay} function
simply outputs a stream where each value is the same as the input
value, but shifted one cycle. This causes a \quote{gap} at the
beginning of the stream: What is the value of the delay output in the
- first cycle? For this, the \hs{delay} function has a second input
- (which is a value, not a stream!).
+ first cycle? For this, the \hs{delay} function has a second input, of
+ which only a single value is used.
\in{Example}[ex:DelayAcc] shows a simple accumulator expressed in this
style.
\item tail has the type \hs{(n > 0) => Vector n -> Vector (n - 1)}
\item This means that xs must have the type \hs{(n > 0) => Vector n}
\item This means that sum must have the type \hs{(n > 0) => Vector n -> a}
+ (The type \hs{a} is can be anything at this stage, we will not try to finds
+ its actual type in this example).
\item sum is called with the result of tail as an argument, which has the
type \hs{Vector n} (since \hs{(n > 0) => Vector (n - 1)} is the same as \hs{(n >= 0)
=> Vector n}, which is the same as just \hs{Vector n}).
projects / matthijs / master-project / report.git / blobdiff