-hardware description languages \cite{Hydra,Hawk1,Lava,ForSyDe1,Wired}
-are embedded as a domain specific language inside 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 domain specific language. The primitive functions used
-to describe a circuit do not actually process any signals, but 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. This circuit 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 circuit 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
-\emph{itself} for the purpose of describing hardware. By taking this approach,
-we can capture certain language constructs, such as Haskell's choice elements
-(if-expressions, case-expressions, 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 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 hardware description language have an
-explicit clock for the purposes state and synchronicity, in the research
-presented in this paper the clock is implied. A developer describes the
-behavior of the hardware between clock cycles. 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. 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.
-
-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{\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.
+\acrop{HDL} \cite{Hydra,Hawk1,Lava,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. This does not mean that circuits specified in an
+embedded language can not contain choice, just that choice elements only
+exists as functions, e.g. a multiplexer function, and not as language
+elements.
+
+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.