+ \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. \cite[gill09]
+ \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 expressions 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: