-functional languages has been proposed \cite{T-Ruby,Hydra,HML2,Hawk1,Lava,
-ForSyDe1,Wired,reFLect}. The idea of using functional languages for hardware
-descriptions started in the early 1980s \cite{Cardelli1981, muFP,DAISY,FHDL},
-a time which also saw the birth of the currently popular hardware description
-languages such as \VHDL. The merit of using a functional language to describe
-hardware comes from the fact that combinatorial circuits can be directly
-modeled as mathematical functions and that functional languages are very good
-at describing and composing mathematical functions.
-
-In an attempt to decrease the amount of work involved with creating all the
-required tooling, such as parsers and type-checkers, many functional hardware
-description languages are embedded as a domain specific language inside the
-functional language Haskell \cite{Hydra,Hawk1,Lava,ForSyDe1,Wired}. This
-means that a developer is given a library of Haskell~\cite{Haskell} functions
-and types that together form the language primitives of the domain specific
-language. As a result of how the signals are modeled and abstracted, the
-functions used to describe a circuit also build a large domain-specific
-datatype (hidden from the designer) which can then be processed further by an
-embedded compiler. This compiler actually runs in the same environment as the
-description; as a result compile-time and run-time become hard to define, as
-the embedded compiler is usually compiled by the same Haskell compiler as the
-circuit description itself.
-
-The approach taken in this research is not to make another domain specific
-language embedded in Haskell, but to use (a subset of) the Haskell language
-itself for the purpose of describing hardware. By taking this approach, we can
-capture certain language constructs, such as Haskell's choice elements
-(if-constructs, case-constructs, pattern matching, etc.), which are not
-available in the functional hardware description languages that are embedded
-in Haskell as a domain specific language. As far as the authors know, such
-extensive support for choice-elements is new in the domain of functional
-hardware description languages. As the hardware descriptions are plain Haskell
-functions, these descriptions can be compiled for simulation using an
-optimizing Haskell compiler such as the Glasgow Haskell Compiler (\GHC)~\cite{ghc}.
-
-Where descriptions in a conventional hardware description language have an
-explicit clock for the purpose state and synchronicity, the clock is implied
-in this research. A developer describes the behavior of the hardware between
-clock cycles. The current abstraction of state and time limits the
-descriptions to synchronous hardware, there however is room within the
-language to eventually add a different abstraction mechanism that will allow
-for the modeling of asynchronous systems. Many functional hardware description
-model signals as a stream of all values over time; state is then modeled as a
-delay on this stream of values. The approach taken in this research is to make
-the current state of a circuit part of the input of the function and the
-updated state part of the output.
-
-Like the standard hardware description languages, descriptions made in a
-functional hardware description language must eventually be converted into a
-netlist. This research also features a prototype translator, which has the
-same name as the language: \CLaSH\footnote{C$\lambda$aSH: CAES Language for
-Synchronous Hardware} (pronounced: clash). This compiler converts the Haskell
-code to equivalently behaving synthesizable \VHDL\ code, ready to be converted
-to an actual netlist format by an (optimizing) \VHDL\ synthesis tool.
-
-Besides trivial circuits such as variants of both the FIR filter and the
-simple CPU shown in \Cref{sec:usecases}, the \CLaSH\ compiler has also been
-shown to work for non-trivial descriptions. \CLaSH\ has been able to
-successfully translate the functional description of a streaming reduction
-circuit~\cite{reductioncircuit} for floating point numbers.
+functional languages has been proposed \cite{Cardelli1981,muFP,DAISY,FHDL,
+T-Ruby,Hydra,HML2,Hawk1,Lava,ForSyDe1,Wired,reFLect}. The idea of using
+functional languages for hardware descriptions started in the early 1980s
+\cite{Cardelli1981,muFP,DAISY,FHDL}, a time which also saw the birth of the
+currently popular hardware description languages, such as \VHDL. Functional
+languages are especially well suited to describe hardware because
+combinational circuits can be directly modeled as mathematical functions and
+functional languages are very good at describing and composing these
+mathematical functions.
+
+In an attempt to decrease the amount of work involved in creating all the
+required tooling, such as parsers and type-checkers, many functional
+\acrop{HDL} \cite{Hydra,Hawk1,Lava,ForSyDe1,Wired} are embedded as a domain
+specific language (\acro{DSL}) within the functional language Haskell
+\cite{Haskell}. This means that a developer is given a library of Haskell
+functions and types that together form the language primitives of the
+\acro{DSL}. The primitive functions used to describe a circuit do not actually
+process any signals, they instead compose a large domain-specific datatype
+(which is usually hidden from the designer). This datatype is then further
+processed by an embedded circuit compiler which can perform for example
+simulation or synthesis. As Haskell's choice elements (\hs{if}-expressions,
+\hs{case}-expressions, etc.) are evaluated at the time the domain-specific
+datatype is being build, they are no longer visible to the embedded compiler
+that processes the datatype. Consequently, it is impossible the capture
+Haskell's choice elements within a circuit description when taking the
+embedded language approach. Descriptions can however still contain
+polymorphism and higher-order functions.
+
+The approach taken in this research is not to make another \acro{DSL} embedded
+in Haskell, but to use (a subset of) the Haskell language \emph{itself} for
+the purpose of describing hardware. By taking this approach, this research
+\emph{can} capture certain language constructs, such as Haskell's choice
+elements, within circuit descriptions. To the best knowledge of the authors,
+supporting polymorphism, higher-order functions and such an extensive array of
+choice-elements is new in the domain of (functional) \acrop{HDL}.
+% As the hardware descriptions are plain Haskell
+% functions, these descriptions can be compiled to an executable binary
+% for simulation using an optimizing Haskell compiler such as the Glasgow
+% Haskell Compiler (\GHC)~\cite{ghc}.
+
+Where descriptions in a conventional \acro{HDL} have an explicit clock for the
+purposes state and synchronicity, the clock is implied in the context of the
+research presented in this paper. A circuit designer describes the behavior of
+the hardware between clock cycles. Many functional \acrop{HDL} model signals
+as a stream of all values over time; state is then modeled as a delay on this
+stream of values. The approach taken in this research is to make the current
+state an additional input and the updated state a part of the output of a
+function. This abstraction of state and time limits the descriptions to
+synchronous hardware, there is however room within the language to eventually
+add a different abstraction mechanism that will allow for the modeling of
+asynchronous systems.
+
+Like the traditional \acrop{HDL}, descriptions made in a functional \acro{HDL}
+must eventually be converted into a netlist. This research also features a
+prototype translator, which has the same name as the language:
+\CLaSH\footnote{\CLaSHtiny: \acrotiny{CAES} Language for Synchronous Hardware}
+(pronounced: clash). This compiler converts the Haskell code to equivalently
+behaving synthesizable \VHDL\ code, ready to be converted to an actual netlist
+format by an (optimizing) \VHDL\ synthesis tool.
+
+Besides trivial circuits such as variants of both the \acro{FIR} filter and
+the simple \acro{CPU} shown in \Cref{sec:usecases}, the \CLaSH\ compiler has
+also been able to successfully translate non-trivial functional descriptions
+such as a streaming reduction circuit~\cite{reductioncircuit} for floating
+point numbers.