Add section on EDSLs.
[matthijs/master-project/report.git] / Chapters / HardwareDescription.tex
index 04b660b4db682bc889bc258cf8c14a58475fbfe0..24afd8965d42722bb87114f6453bd049dbac84f9 100644 (file)
@@ -804,7 +804,9 @@ acc in s = (s', out)
         has to somehow know the current state for these called functions. The
         only way to do this, is to put these \emph{substates} inside the
         caller's state. This means that a function's state is the sum of the
         has to somehow know the current state for these called functions. The
         only way to do this, is to put these \emph{substates} inside the
         caller's state. This means that a function's state is the sum of the
-        states of all functions it calls, and its own state.
+        states of all functions it calls, and its own state. This sum
+        can be obtained using something simple like a tuple, or possibly
+        custom algebraic types for clarity.
 
         This also means that the type of a function (at least the "state"
         part) is dependent on its own implementation and of the functions it
 
         This also means that the type of a function (at least the "state"
         part) is dependent on its own implementation and of the functions it
@@ -883,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.