Various small fixes following from Bert's commentaar.

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

diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex
index 3be5e3a64dc664aa7c40b6d2c09c5e50408c93e9..48c69b9d0f50bdfb1dd71c95994f13ff504e9457 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
@@ -318,7 +331,7 @@
       \startlambda
       λbndr.body
       \stoplambda
-      This is the basic lambda abstraction, as it occurs in labmda calculus.
+      This is the basic lambda abstraction, as it occurs in lambda calculus.
       It consists of a binder part and a body part.  A lambda abstraction
       creates a function, that can be applied to an argument. The binder is
       usually a value binder, but it can also be a \emph{type binder} (or
@@ -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