+ An obvious question that arises when starting any research is \quote{Hasn't
+ this been done before?} Using a functional language for describing hardware
+ is not a new idea at all. In fact, there has been research into functional
+ hardware description even before the conventional hardware description
+ languages were created. However, functional languages were not nearly as
+ advanced as they are now, and functional hardware description never really
+ got off.
+
+ Recently, there have been some renewed efforts, especially using the Haskell
+ language. Examples are Lava, ForSyde, ..., which are all a form of an
+ embedded domain specific language. Each of these have a slightly different
+ approach, but all of these do some trickery inside the Haskell language
+ itself, meaning you write a program that generates a hardware circuit,
+ instead of describing the circuit directly (either by running the haskell
+ code after compilation, or using Template Haskell to inspect parts of the
+ code you have written). This allows the full power of Haskell for generating
+ a circuit, but only it also creates severe limitations in the use of the
+ language (you can't use case statements in Lava, since they would be
+ executed only once during circuit generation) and extra notational overhead.
+
+TODO: Define (E)DSL
+TODO: References
+
+ \section{Conventional hardware description languages}
+ Considering that we already have some hardware description language like
+ \small{VHDL} and Verilog, why would we need anything else? By introducing
+ the functional style to hardware description, we hope to obtain a hardware
+ description language that is:
+ \startitemize
+ \item More consise. Functional programs are known for their conciseness,
+ mostly caused by the ability to abstract just about any behaviour into a
+ helper function. This is largely enabled by features like an advanced
+ type system with polymorphism and higher order functions.
+ \item Type-safer. Functional programs typically have a highly expressive
+ type system, which makes it harder to write incorrect code. This is
+ probably not only directly caused by the type system, so perhaps this
+ advantage does not apply in hardware descriptions.
+ \item Easy to process. Functional languages have nice properties like
+ purity \refdef{purity} and single binding behaviour, which make it easy
+ to apply program transformations and optimizations and could potentially
+ simplify program verification.
+ \stopitemize
+
+ \section{Existing functional hardware description languages}
+ As noted above, we're not the first to walk this path. However, current
+ embedded functional hardware description languages (in particular those
+ using Haskell) are limited by:
+ \startitemize
+ \item Not all of Haskell's constructs can be captured by embedded domain
+ specific languages. For example, an if or case expression is typically
+ executed only once and only its result is reflected in the embedded
+ description, not the if or case expression itself. Also, sharing and
+ loops are non-trivial do properly and safely translate (though there is
+ some work to fix this, but that has not been possible in a completely
+ reliable way yet. TODO: ref
+ http://www.ittc.ku.edu/~andygill/paper.php?label=DSLExtract09).
+ \item Some things are verbose to express. Especially ForSyDe suffers
+ from a lot of notational overhead due to the Template Haskell approach
+ used. Since conditional statements are not supported, a lot of Haskell's
+ syntax sugar (if expressions, pattern matching, guards) cannot be used
+ either, leading to more verbose notation as well.
+ \item Polymorphism and higher order values are not supported within the
+ embedded language. The use of Haskell as a host language allows the use
+ of polymorphism and higher order functions at circuit generation time
+ (even for free, without any additional cost on the \small{EDSL}
+ programmers), but the described circuits do not have any polymorphism
+ or higher order functions, which can be limiting (TODO: How true or
+ appropriate is this point?).
+ \stopitemize