Replace statement with expression everywhere.

[matthijs/master-project/report.git] / Chapters / Prototype.tex

diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex
index 3be5e3a64dc664aa7c40b6d2c09c5e50408c93e9..40663f37cf2edb95d728da97f2e41d7e4e1cbc4b 100644 (file)
--- a/Chapters/Prototype.tex
+++ b/Chapters/Prototype.tex
@@ -30,8 +30,22 @@
       development.
     \stopitemize
 
-    \todo{Sidenote: No EDSL}
 
+    \placeintermezzo{}{
+      \startframedtext[width=8cm,background=box,frame=no]
+      \startalignment[center]
+        {\tfa No \small{EDSL} or Template Haskell}
+      \stopalignment
+      \blank[medium]
+
+      Note that in this consideration, embedded domain-specific
+      languages (\small{EDSL}) and Template Haskell (\small{TH})
+      approaches have not been included. As we've seen in
+      \in{section}[sec:context:fhdls], these approaches have all kinds
+      of limitations on the description language that we would like to
+      avoid.
+      \stopframedtext
+    }
     Considering that we required a prototype which should be working quickly,
     and that implementing parsers, semantic checkers and especially
     typcheckers is not exactly the core of this research (but it is lots and
@@ -66,8 +80,7 @@
     However, \small{EDIF} is not completely tool-independent. It specifies a
     meta-format, but the hardware components that can be used vary between
     various tool and hardware vendors, as well as the interpretation of the
-    \small{EDIF} standard. \todo{Is this still true? Reference:
-    http://delivery.acm.org/10.1145/80000/74534/p803-li.pdf?key1=74534\&key2=8370537521\&coll=GUIDE\&dl=GUIDE\&CFID=61207158\&CFTOKEN=61908473}
+    \small{EDIF} standard. \cite[li89]
    
     This means that when working with \small{EDIF}, our prototype would become
     technology dependent (\eg only work with \small{FPGA}s of a specific
@@ -438,12 +451,12 @@
       binder, even when strictness was involved.  Nonetheless, the prototype
       handles this binder as expected.
 
-      Note that these case statements are less powerful than the full Haskell
-      case statements. In particular, they do not support complex patterns like
+      Note that these case expressions are less powerful than the full Haskell
+      case expressions. In particular, they do not support complex patterns like
       in Haskell. Only the constructor of an expression can be matched,
       complex patterns are implemented using multiple nested case expressions.
 
-      Case statements are also used for unpacking of algebraic datatypes, even
+      Case expressions are also used for unpacking of algebraic datatypes, even
       when there is only a single constructor. For examples, to add the elements
       of a tuple, the following Core is generated:
 
@@ -982,7 +995,7 @@
         \emph{one} application, no more and no less.
 
         The function result should contain exactly one state variable, which
-        can be extracted using (multiple) case statements. The extracted
+        can be extracted using (multiple) case expressions. The extracted
         state variable is referred to the \emph{output substate}
 
         The type of this output substate must be identical to the type of