-\section{\acrlong{TOP}}
-\subsection{\gls{iTasks}}
-\gls{TOP} is a recent new programming paradigm implemented as
+\section{iTasks}
+\gls{TOP} is a recent programming paradigm implemented as
\gls{iTasks}\cite{achten_introduction_2015} in the pure lazy functional
language \gls{Clean}\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a
\gls{EDSL} to model workflow tasks in the broadest sense. A \CI{Task} is just
-a function that, given some state, returns the observable \CI{TaskValue}. The
+a function that --- given some state --- returns the observable \CI{TaskValue}. The
\CI{TaskValue} of a \CI{Task} can have different states. Not all state
transitions are possible as shown in Figure~\ref{fig:taskvalue}. Once a value
-has gone stable it can never become unstable again. Stability is often reached
-by pressing a confirmation button or for \glspl{Task} that offer a constant
-value. A simple example is shown in Listing~\ref{lst:taskex} accompanied with
-Figure~\ref{fig:taskex1},~\ref{fig:taskex2} and~\ref{fig:taskex3}. In this
-example the first image in is the \CI{NoValue} state, the second and third
-image are in the \CI{Unstable} state. When the user presses \emph{Continue} the
-value becomes \CI{Stable}.
+is stable it can never become unstable again. Stability is often reached
+by pressing a confirmation button. \glspl{Task} yielding a constant value are
+immediately stable.
+
+A simple \gls{iTasks} example illustrating the route to stability of a
+\gls{Task} in which the user has to enter a full name is shown in
+Listing~\ref{lst:taskex}. The code is accompanied by screenshots showing the
+user interface in Figure~\ref{fig:taskex1},~\ref{fig:taskex2}
+and~\ref{fig:taskex3}. The \CI{TaskValue} of the \gls{Task} is in the first
+image in the \CI{NoValue} state, the second image does not have all the fields
+filled in and therefore the \CI{TaskValue} remains \CI{Unstable}. In the third
+image all fields are entered and the \CI{TaskValue} transitions to the
+\CI{Unstable} state. When the user presses \emph{Continue} the value becomes
+\CI{Stable} and cannot be changed any further.
\begin{figure}[H]
\centering
\begin{lstlisting}[language=Clean,label={lst:taskex},%
caption={An example \gls{Task} for entering a name}]
-:: Name = { firstname :: String
- , lastname :: String
- }
+:: Name = { firstname :: String
+ , lastname :: String
+ }
derive class iTask Name
specialization instances for these functions and show an according interface.
Generated interfaces can be modified with decoration operators.
-\subsection{Combinators}
-\todo{Stukje over combinators, in ieder geval bind en paralel}
+\section{Combinators}
+\Glspl{Task} can be combined using so called \gls{Task}-combinators.
+Combinators describe relations between \glspl{Task}. \Glspl{Task} can be
+combined in parallel, sequenced and their result values can be converted to
+\glspl{SDS}. Moreover, a very important combinator is the step combinator which
+starts a new task according to specified predicates on the \CI{TaskValue}.
+Type signatures of the basic combinators are shown in
+Listing~\ref{lst:combinators}.
+
+\begin{itemize}
+ \item Step:
+
+ The step combinator is used to start \glspl{Task} when a predicate on
+ the \CI{TaskValue} holds or an action has taken place. The bind
+ operator can be written as a step combinator.
+ \begin{lstlisting}[language=Clean]
+(>>=) infixl 1 :: (Task a) (a -> (Task b)) -> (Task b) | iTask a & iTask b
+(>>=) ta f = ta >>* [OnAction "Continue" onValue, OnValue onStable]
+ where
+ onValue (Value a _) = Just (f a)
+ onValue _ = Nothing
+
+ onStable (Value a True) = Just (f a)
+ onStable _ = Nothing
+ \end{lstlisting}
+ \item Parallel:
+
+ The parallel combinator allows for concurrent \glspl{Task}. The
+ \glspl{Task} combined with these operators will appear at the same time
+ in the web browser of the user and the results are combined as the type
+ dictates.
+\end{itemize}
+
+\begin{lstlisting}[language=Clean,%
+ caption={\Gls{Task}-combinators},label={lst:combinators}]
+//Step combinator
+(>>*) infixl 1 :: (Task a) [TaskCont a (Task b)] -> Task b | iTask a & iTask b
+(>>=) infixl 1 :: (Task a) (a -> Task b) -> Task b | iTask a & iTask b
+:: TaskCont a b
+ = OnValue ((TaskValue a) -> Maybe b)
+ | OnAction Action ((TaskValue a) -> Maybe b)
+ | E.e: OnException (e -> b) & iTask e
+ | OnAllExceptions (String -> b)
+:: Action = Action String
+
+//Parallel combinators
+(-||-) infixr 3 :: (Task a) (Task a) -> Task a | iTask a
+(||-) infixr 3 :: (Task a) (Task b) -> Task b | iTask a & iTask b
+(-||) infixl 3 :: (Task a) (Task b) -> Task a | iTask a & iTask b
+(-&&-) infixr 4 :: (Task a) (Task b) -> Task (a,b) | iTask a & iTask b
+\end{lstlisting}
+
+\section{\acrlongpl{SDS}}
+\Glspl{SDS} are an abstraction over resources that are available in the world
+or in the \gls{iTasks} system. The shared data can be a file on disk, it can be
+the time, a random integer or just some data stored in memory. The actual
+\gls{SDS} is just a record containing functions on how to read and write the
+source. In these functions the \CI{*World} is available and therefore it can
+interact with the outside world. The \CI{*IWorld} is also available and
+therefore the functions can also access other shares, possibly combining them.
+
+The basic operations for \glspl{SDS} are get, set and update. The signatures
+for these functions are shown in Listing~\ref{lst:shares}. All of the
+operations are atomic in the sense that during reading no other tasks are
+executed.
+
+\begin{lstlisting}[%
+ language=Clean,label={lst:shares},caption={\Gls{SDS} functions}]
+get :: (ReadWriteShared r w) -> Task r | iTask r
+set :: w (ReadWriteShared r w) -> Task w | iTask w
+upd :: (r -> w) (ReadWriteShared r w) -> Task w | iTask r & iTask w
+
+\end{lstlisting}