\chapter[chap:context]{Context}
-Other FHDLs (short, Christiaan has details)
-Advantages of clash / why clash?
+ An obvious question that arises when starting any research is \quote{Has
+ this not 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. \todo{Reference about early FHDLs} However,
+ functional languages were not nearly as advanced as they are now, and
+ functional hardware description never really got off.
+
+\todo{Add references}
+ Recently, there have been some renewed efforts, especially using the Haskell
+ functional 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. However 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.
+
+\fxnote{There should be a section on DSLs here}
+
+ We will now have a look at the existing hardware description languages,
+ both conventional and functional to see the fields in which Cλash is
+ operating.
+
+ \section{Conventional hardware description languages}
+ Considering that we already have some hardware description languages 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
+ and ability to abstract away common patterns. This is largely enabled
+ by features like an advanced type system with polymorphism and higher
+ order functions.
+ \todo{Does this apply to FHDLs equally?}
+ \item Type-safer. Functional programs typically have a highly expressive
+ type system, which makes it harder to write incorrect code.
+ \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:\todo{Separate TH and EDSL approaches
+ better}
+ \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 of
+ variables (\eg, using the same variable twice while only calculating it
+ once) and cycles in circuits are non-trivial to 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?}
+ \todo[left]{Function structure gets lost (in Lava)}
+ \stopitemize
+
+ \todo[text]{Complete translation in TH is complex: Works with Haskell AST
+ instead of Core}
+
+% vim: set sw=2 sts=2 expandtab:
projects / matthijs / master-project / report.git / blobdiff