Add reference.
authorMatthijs Kooijman <matthijs@stdin.nl>
Wed, 9 Dec 2009 09:34:48 +0000 (10:34 +0100)
committerMatthijs Kooijman <matthijs@stdin.nl>
Wed, 9 Dec 2009 09:35:27 +0000 (10:35 +0100)
Chapters/Future.tex
Chapters/Prototype.tex

index 523fc0a8a1a6d3313bb8354cb6e08e977159a993..8cfd12741e980970e49a04bfee4a1f42c003b3f5 100644 (file)
@@ -214,8 +214,9 @@ happening.
 
 An important implication of this approach is that the order of writing
 function applications affects the state type. Fortunately, this problem can be
 
 An important implication of this approach is that the order of writing
 function applications affects the state type. Fortunately, this problem can be
-localized by consistently using type synonyms for state types, which should
-prevent changes in other function's source when a function changes.
+localized by consistently using type synonyms for state types (see
+\in{section}[sec:prototype:substatesynonyms]), which should prevent
+changes in other function's source when a function changes.
 
 A less obvious implications of this approach is that the scope of variables
 produced by each of these expressions (using the \hs{<-} syntax) is limited to
 
 A less obvious implications of this approach is that the scope of variables
 produced by each of these expressions (using the \hs{<-} syntax) is limited to
@@ -223,8 +224,6 @@ the expressions that come after it. This prevents values from flowing between
 two functions (components) in two directions. For most Monad instances, this
 is a requirement, but here it could have been different.
 
 two functions (components) in two directions. For most Monad instances, this
 is a requirement, but here it could have been different.
 
-\todo{Add examples or reference for state synonyms}
-
 \subsection{Alternative syntax}
 Because of these typing issues, misusing Haskell's do notation is probably not
 the best solution here. However, it does show that using fairly simple
 \subsection{Alternative syntax}
 Because of these typing issues, misusing Haskell's do notation is probably not
 the best solution here. However, it does show that using fairly simple
index 720053c4f83a6b818fc3416d464696d0d81f8d1c..870b7ccc0266e75930a09947b1c103cc9c5ddec2 100644 (file)
       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