Make a small start on the state annotations section.
authorMatthijs Kooijman <matthijs@stdin.nl>
Fri, 4 Dec 2009 09:48:10 +0000 (10:48 +0100)
committerMatthijs Kooijman <matthijs@stdin.nl>
Fri, 4 Dec 2009 09:48:10 +0000 (10:48 +0100)
Chapters/HardwareDescription.tex
Chapters/Prototype.tex

index f5c0eaa59722a62d7783c769df97df4486ae2691..24afd8965d42722bb87114f6453bd049dbac84f9 100644 (file)
@@ -885,7 +885,7 @@ acc in s = (s', out)
 
         \todo{Sidenote: One or more state arguments?}
 
 
         \todo{Sidenote: One or more state arguments?}
 
-    \subsection{Explicit state annotation}
+    \subsection[sec:description:stateann]{Explicit state annotation}
       To make our stateful descriptions unambigious and easier to translate,
       we need some way for the developer to describe which arguments and
       results are intended to become stateful.
       To make our stateful descriptions unambigious and easier to translate,
       we need some way for the developer to describe which arguments and
       results are intended to become stateful.
index 139b93e56be69f2637efcffc785935e95bb77b9c..67d23c8b2be60ee6c06f78fc73bcc18b59afc560 100644 (file)
       here)}.
         
   \section[sec:prototype:statetype]{State annotations in Haskell}
       here)}.
         
   \section[sec:prototype:statetype]{State annotations in Haskell}
+    As noted in \in{section}[sec:description:stateann], Cλash needs some
+    way to let the programmer explicitly specify which of a function's
+    arguments and which part of a function's result represent the
+    function's state.
       \fxnote{This entire section on state annotations should be reviewed}
 
       Ideal: Type synonyms, since there is no additional code overhead for
       \fxnote{This entire section on state annotations should be reviewed}
 
       Ideal: Type synonyms, since there is no additional code overhead for