-Hardware description languages (\acrop{HDL}) have allowed the productivity of
-hardware engineers to keep pace with the development of chip technology.
-Traditional \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,
-T-Ruby,HML2,Hydra,Hawk1,Lava,Wired,ForSyDe1,reFLect}. The idea of using
-functional languages for hardware descriptions started in the early 1980s
-\cite{Cardelli1981,muFP,DAISY}, a time which also saw the birth of the
-currently popular \acrop{HDL}, 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
-functions.
-
-In an attempt to ease the prototyping process of the language, such as
-creating all the required tooling, like parsers and type-checkers, many
-functional \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 graph
-(which is usually hidden from the designer). This graph is then further
-processed by an embedded circuit compiler which can perform for example
-simulation or synthesis. As Haskell's choice elements (\hs{case}-expressions,
-pattern-matching etc.) are evaluated at the time the domain-specific graph is
-being build, they are no longer visible to the embedded compiler that
-processes the datatype. Consequently, it is impossible to 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 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, like
-all of Haskell's choice elements, within circuit descriptions. The more
-advanced features of Haskel, such as polymorphic typing and higher-order
-function, are also supported.
+Hardware description languages (\acrop{HDL}) have not allowed the productivity
+of hardware engineers to keep pace with the development of chip technology.
+While traditional \acrop{HDL}, like \VHDL~\cite{VHDL2008} and
+Verilog~\cite{Verilog}, are very good at describing detailed hardware
+properties such as timing behavior, they are generally cumbersome in
+expressing the higher-level abstractions needed for today's large and complex
+circuit designs. In an attempt to raise the abstraction level of the
+descriptions, a great number of approaches based on functional languages have
+been proposed \cite{Cardelli1981,muFP,DAISY,FHDL,T-Ruby,HML2,Hydra,Hawk1,Lava,
+Wired,ForSyDe1,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 \acrop{HDL}, 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 functions.
+
+In an attempt to reduce the effort involved with prototyping a new
+language, such as creating all the required tooling like parsers and
+type-checkers, many functional \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
+graph (which is usually hidden from the designer). This graph is then further
+processed by an embedded circuit compiler which can perform e.g. simulation or
+synthesis. As Haskell's choice elements (\hs{case}-expressions,
+pattern-matching, etc.) are evaluated at the time the graph is being build,
+they are no longer visible to the embedded compiler that processes the graph.
+Consequently, it is impossible to 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 exist as functions, e.g. a multiplexer
+function, and not as syntactic elements of the language itself.
+
+This research uses (a subset of) the Haskell language \emph{itself} for the
+purpose of describing hardware. As a result, certain language constructs, like
+all of Haskell's choice elements, \emph{can} now be captured within circuit
+descriptions. Advanced features of Haskell, such as polymorphic typing and
+higher-order functions, are also supported.