Add some more context.

diff --git a/Chapters/Context.tex b/Chapters/Context.tex
index 4b529c924afcb2e3130486de69874805b2be30e6..827f61f5506f5f9bfab3c61b863683ab8720f704 100644 (file)
--- a/Chapters/Context.tex
+++ b/Chapters/Context.tex
@@ -22,15 +22,49 @@
 TODO: Define (E)DSL
 TODO: References
 
-  Advantages over conventional HDLs
-   - More consise
-   - More expressive
-   - Easy to transform / optimize / etc.
-
-  Advantages over existing FHDLs
-   - More control
-   - Full Haskell available
-   - Concise notation
-
-  Disadvantages over existing FHDLs
-   - More work to implement advanced things
+  \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