-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 e.g. 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 syntactic elements of the language
-itself.
-
-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 Haskell, such as polymorphic typing and higher-order
-functions, are also supported.
+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 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 syntactic elements of the language itself.
+
+This research is uses (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. Advanced features of Haskell, such as polymorphic typing and higher-order functions, are also supported.