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
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
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}
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