- 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)}
+ specific languages. For example, an \hs{if} or \hs{case}
+ expression is typically executed once when the Haskell description
+ is processed and only the result is reflected in the generated
+ data-structure (and thus in the final program). In Lava, for
+ example, conditional assignment can only be described by using
+ explicit multiplexer components, not using any of Haskell's
+ compact mechanisms (such as \hs{case} expressions or pattern
+ matching).
+
+ 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 Template Haskell makes descriptions verbose. Template
+ Haskell needs extra annotations to move things around between
+ \small{TH} and the normal program. When \small{TH} is combined
+ with an \small{EDSL} approach, it can get confusing when to use
+ \small{TH} and when not to.
+ \item Function hierarchies cannot be observed in an \small{EDSL}.
+ For example, Lava generates a single flat \VHDL\ architecture,
+ which has no structure whatsoever. Even though this is strictly
+ correct, it offers no support to the synthesis software about
+ which parts of the system can best be placed together and makes
+ debugging the system very hard.
+
+ It is possible to add explicit annotation to overcome this
+ limitation (ForSyDe does this using Template Haskell), but this
+ adds extra verbosity again.
+ \item Processing in Template Haskell can become very complex,
+ since it works on the Haskell \small{AST} directly. This means
+ that every part of the Haskell syntax that is used must be
+ supported explicitly by the Template Haskell code.
+ \in{Chapter}[chap:prototype] shows that working on a smaller
+ \small{AST} is much more efficient.