\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.
+
+ 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
+
+ \placeintermezzo{}{
+ \defref{EDSL}
+ \startframedtext[width=8.5cm,background=box,frame=no]
+ \startalignment[center]
+ {\tfa Embedded domain-specific languages (\small{EDSL})}
+ \stopalignment
+ \blank[medium]
+
+ \startcitedquotation[hudak96]
+ A domain-specific language (\small{DSL}) is a program-
+ ming language or executable specification language
+ that offers, through appropriate notations and ab-
+ stractions, expressive power focused on, and usu-
+ ally restricted to, a particular problem domain.
+ \stopcitedquotation
+
+ \todo{ref: http://portal.acm.org/citation.cfm?id=352035\&dl=}
+
+ An embedded \small{DSL} is a \small{DSL} that is embedded in
+ another language. Haskell is commonly used to embed \small{DSL}s
+ in, which typically means a number of Haskell functions and types
+ are made available that can be called to construct a large value
+ of some domain-specific datatype (\eg, a circuit datatype). This
+ generated datatype can then be processed further by the
+ \small{EDSL} \quote{compiler} (which runs in the same environment
+ as the \small{EDSL} itself. The embedded language is then a, mostly
+ applicative, subset of Haskell where the library functions are the
+ primitives. Sometimes advanced haskell features such as
+ polymorphism, higher order values or type classes can be used in
+ the embedded language.
+ \stopframedtext
+ }
+
+ \section[sec:context:fhdls]{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