Remove some progress documents, they are being stored elsewhere.
[matthijs/master-project/report.git] / Chapters / Prototype.tex
index 720053c4f83a6b818fc3416d464696d0d81f8d1c..23168242ccc098c594b8ae291db2b80ccb04b5a8 100644 (file)
         of a case expression to normal form (evaluating any function
         applications, variable references and case expressions) is
         sufficient to decide which case alternatives should be chosen.
         of a case expression to normal form (evaluating any function
         applications, variable references and case expressions) is
         sufficient to decide which case alternatives should be chosen.
-        \todo{ref?}
       \stopframedtext
 
     }
       \stopframedtext
 
     }
       We cannot leave all these \hs{State} type constructors out, since that
       would change the type (unlike when using type synonyms). However, when
       using type synonyms to hide away sub-states (see
       We cannot leave all these \hs{State} type constructors out, since that
       would change the type (unlike when using type synonyms). However, when
       using type synonyms to hide away sub-states (see
-      \in{section}[sec:prototype:sub-statesynonyms] below), this
+      \in{section}[sec:prototype:substatesynonyms] below), this
       disadvantage should be limited.
 
       \subsubsection{Different input and output types}
       disadvantage should be limited.
 
       \subsubsection{Different input and output types}
         and output state types, possible reducing the type-safety of the
         descriptions.
 
         and output state types, possible reducing the type-safety of the
         descriptions.
 
-    \subsection[sec:prototype:sub-statesynonyms]{Type synonyms for sub-states}
+    \subsection[sec:prototype:substatesynonyms]{Type synonyms for sub-states}
       As noted above, when using nested (hierarchical) states, the state types
       of the \quote{upper} functions (those that call other functions, which
       call other functions, etc.) quickly become complicated. Also, when the
       As noted above, when using nested (hierarchical) states, the state types
       of the \quote{upper} functions (those that call other functions, which
       call other functions, etc.) quickly become complicated. Also, when the
 
       When applying these rules to the function \lam{avg} from
       \in{example}[ex:AvgStateNormal], we be left with the description
 
       When applying these rules to the function \lam{avg} from
       \in{example}[ex:AvgStateNormal], we be left with the description
-      in \in{example}[ex:AvgStateRemoved]. All the parts that do not
-      generate any \VHDL\ directly are crossed out, leaving just the
-      actual flow of values in the final hardware. To illustrate the
-      change of the types of \lam{s} and \lam{s'}, their types are also
-      shown.
+      below. All the parts that do not generate any \VHDL\ directly are
+      crossed out, leaving just the actual flow of values in the final
+      hardware. To illustrate the change of the types of \lam{s} and \lam{s'},
+      their types are also shown.
       
       \startbuffer[AvgStateRemoved]
         avg = iλ.λ--spacked.--
       
       \startbuffer[AvgStateRemoved]
         avg = iλ.λ--spacked.--
           in
             res
       \stopbuffer
           in
             res
       \stopbuffer
-      \placeexample[here][ex:AvgStateRemoved]{Normalized version of \in{example}[ex:AvgState] with ignored parts crossed out}
-          {\typebufferlam{AvgStateRemoved}}
+      \typebufferlam{AvgStateRemoved}
               
       When we actually leave out the crossed out parts, we get a slightly
       weird program: there is a variable \lam{s} which has no value, and there
               
       When we actually leave out the crossed out parts, we get a slightly
       weird program: there is a variable \lam{s} which has no value, and there