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}
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.
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