always inline the binding operators to reveal the flow of values).
This highlights an important aspect of using a functional language for our
-descriptions: We can use the language itself to provide abstractions of common
+descriptions: we can use the language itself to provide abstractions of common
patterns, making our code smaller and easier to read.
\subsection{Breaking out of the Monad}
\subsection{Arrows}
Another abstraction mechanism offered by Haskell are arrows. Arrows are
-a generalisation of monads \cite[hughes98], for which \GHC also supports
+a generalisation of monads \cite[hughes98], for which \GHC\ also supports
some syntax sugar \cite[paterson01]. Their use for hiding away state
boilerplate is not directly evident, but since arrows are a complex
concept further investigation is appropriate.
behaviour is not needed.
The main cost of this approach will probably be extra complexity in the
-compiler: The paths (state) data can take become very non-trivial, and it
+compiler: the paths (state) data can take become very non-trivial, and it
is probably hard to properly analyze these paths and produce the
-intended \VHDL description.
+intended \VHDL\ description.
\section{Multiple cycle descriptions}
In the current Cλash prototype, every description is a single-cycle
Naively, this matching could be done using a (built-in) function with a
signature like \lam{[a] -> a}, which also serves as an indicator to the
compiler that some expanding over time is required. However, this poses a
-problem for simulation: How will our Haskell implementation of this magical
+problem for simulation: how will our Haskell implementation of this magical
built-in function know which element of the input list to return. This
obviously depends on the current cycle number, but there is no way for this
function to know the current cycle without breaking all kinds of safety and
value disappears.
This approach is commonly known as the \quote{Reynolds approach to
-defuntionalization}, first described by J.C. Reynolds \cite[reynolds98] and
+defuntionalization}, first described by J.C. Reynolds \cite[reynolds98]\ and
seems to apply well to this situation. One note here is that Reynolds'
approach puts all the higher-order values in a single datatype. For a typed
language, we will at least have to have a single datatype for each function
probably a non-trivial problem, though.
\section{Don't care values}
- A powerful value in \VHDL is the \emph{don't care} value, given as
+ A powerful value in \VHDL\ is the \emph{don't care} value, given as
\type{'-'}. This value tells the compiler that you do not really care about
which value is assigned to a signal, allowing the compiler to make some
optimizations. Since choice in hardware is often implemented using
This would also require some kind of \quote{Don't careable} type class
that allows each type to specify what its don't care value is. The
compiler must then recognize this constant and replace it with don't care
- values in the final \VHDL code.
+ values in the final \VHDL\ code.
This is of course a very intrusive solution. Every type must become member
of this type class, and there is now some member in every type that is a