-Hardware description languages have allowed the productivity of hardware
-engineers to keep pace with the development of chip technology. Standard
-Hardware description languages, like \VHDL~\cite{VHDL2008} and
-Verilog~\cite{Verilog}, allowed an engineer to describe circuits using a
-programming language. These standard languages are very good at describing
-detailed hardware properties such as timing behavior, but are generally
-cumbersome in expressing higher-level abstractions. In an attempt to raise the
-abstraction level of the descriptions, a great number of approaches based on
-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
+Hardware description languages (\acrop{HDL}) have allowed the productivity of
+hardware engineers to keep pace with the development of chip technology.
+Standard \acrop{HDL}, like \VHDL~\cite{VHDL2008} and Verilog~\cite{Verilog},
+allowed an engineer to describe circuits using a `programming' language. These
+standard languages are very good at describing detailed hardware properties
+such as timing behavior, but are generally cumbersome in expressing
+higher-level abstractions. In an attempt to raise the abstraction level of the
+descriptions, a great number of approaches based on 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. Furthermore, functional languages are very
+good at describing and composing 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}) 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
+\acro{DSL}. 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.
+Though the embedded language approach still allows for the support of
+polymorphism and higher-order functions, it impossible to capture Haskell's
+choice elements within a circuit description.
+
+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, we \emph{can}