\section{iTasks}
\gls{TOP} is a novel 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 an
\gls{EDSL} to model workflow tasks in the broadest sense. A \gls{Task} is just
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
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
	\includegraphics[width=.5\linewidth]{fig-taskvalue}
	\caption{The states of a \CI{TaskValue}}\label{fig:taskvalue}
\end{figure}

\begin{lstlisting}[label={lst:taskex},%
	caption={An example \gls{Task} for entering a name}]
:: Name = { firstname :: String
          , lastname  :: String
          }

derive class iTask Name

enterInformation :: String [EnterOption m] -> (Task m) | iTask m

enterName :: Task Name
enterName = enterInformation "Enter your name" []
\end{lstlisting}

\begin{figure}[H]
	\centering
	\begin{subfigure}{.25\textwidth}
		\centering
		\includegraphics[width=.9\linewidth]{taskex1}
		\caption{Initial interface}\label{fig:taskex1}
	\end{subfigure}
	\begin{subfigure}{.25\textwidth}
		\centering
		\includegraphics[width=.9\linewidth]{taskex2}
		\caption{Incomplete entrance}\label{fig:taskex2}
	\end{subfigure}
	\begin{subfigure}{.25\textwidth}
		\centering
		\includegraphics[width=.9\linewidth]{taskex3}
		\caption{Complete entry}\label{fig:taskex3}
	\end{subfigure}
	\caption{Example of a generated user interface}
\end{figure}

For a type to be suitable, it must have instances for a collection of generic
functions that is captured in the class \CI{iTask}. Basic types have
specialization instances for these functions and show an interface accordingly.
Derived interfaces can be modified with decoration operators or specializations
can be created.

\section{Combinators}
\Glspl{Task} can be combined using so called \gls{Task}-combinators.
Combinators describe relations between \glspl{Task}. There are only two basic
types of combinators; namely parallel and sequence. All other combinators are
derived from the basic combinators. Type signatures of simplified versions of
the basic combinators and their derivations are given in
Listing~\ref{lst:combinators}

\begin{lstlisting}[%
	caption={\Gls{Task}-combinators},label={lst:combinators}]
//Step combinator
(>>=)  infixl 1 :: (Task a) (a -> Task b)         -> Task b   | iTask a & iTask b
(>>*)  infixl 1 :: (Task a) [TaskCont 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}

\paragraph{Sequence:}
The implementation for the sequence combinator is called the
\CI{step} (\CI{>>*}). This combinator runs the left-hand \gls{Task} and
starts the right-hand side when a certain predicate holds. Predicates
can be propositions about the \CI{TaskValue}, user actions from within
the web browser or a thrown exception. The familiar
bind-combinator is an example of a sequence combinator. This combinator
runs the left-hand side and continues to the right-hand \gls{Task} if
there is an \CI{UnStable} value and the user presses continue or when
the value is \CI{Stable}. The combinator could have been implemented
as follows:
\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}

\paragraph{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. All parallel combinators used are derived from the basic parallel
combinator that is very complex and only used internally.

\section{Shared Data Sources}
\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, the
system 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{*IWorld} --- which in turn contains the real
\CI{*World} --- is available. Accessing the outside world is required for
interacting with it and thus the functions can access files on disk, raw
memory, other \glspl{SDS} and hardware.

The basic operations for \glspl{SDS} are get, set and update. The signatures
for these functions are shown in Listing~\ref{lst:shares}. By default, all
\glspl{SDS} are files containing a \gls{JSON} encoded version of the object and
thus are persistent between restarts of the program. Library functions for
shares residing in memory are available as well. The three main operations on
shares are atomic in the sense that during reading no other \glspl{Task} are
executed.  The system provides useful functions to transform, map and combine
\glspl{SDS} using combinators. The system also provides functionality to
inspect the value of a \gls{SDS} and act upon a change. \Glspl{Task} waiting on
a \gls{SDS} to change are notified when needed. This results in low resource
usage because \glspl{Task} are never constantly inspecting \gls{SDS} values but
are notified.

\begin{lstlisting}[%
	label={lst:shares},caption={\Gls{SDS} functions}]
:: RWShared p r w = ... 
:: ReadWriteShared r w :== RWShared () r w
:: ROShared p r :== RWShared p () r
:: ReadOnlyShared r :== ROShared () r

:: Shared r :== ReadWriteShared r r

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

sharedStore :: String a -> Shared a | JSONEncode{|*|}, JSONDecode{|*|}
\end{lstlisting}

\section{Parametric Lenses}
\Glspl{SDS} can contain complex data structures such as lists, trees and even
resources in the outside world. Sometimes, an update action only updates a part
of the resource. When this happens, all waiting \glspl{Task} looking at the
resource are notified of the update. However, it may be the case that
\glspl{Task} were only looking at parts of the structure that was not updated.
To solve this problem, parametric lenses were
introduced~\cite{domoszlai_parametric_2014}.

Parametric lenses add a type variable to the \gls{SDS} that is in the current
library functions fixed to the void type (i.e. \CI{()}). When a \gls{SDS}
executes a write operation, it also provides the system with a notification
predicate. This notification predicate is a function \CI{p -> Bool} where
\CI{p} is the parametric lens type. This allows programmers to create a big
\gls{SDS}, and have \glspl{Task} only look at parts of the big \gls{SDS}. This
technique is used in the current system in memory shares. The \CI{IWorld}
contains a map that is accessible through a \gls{SDS}. While all data is
stored in the map, only \glspl{Task} looking at a specific entry are notified
when the structure is updated. The type of the parametric lens is the key in
the map.

Functionality for setting parameters is added in the system. The most important
functions are the \CI{sdsFocus} and the \CI{sdsLens} function. These functions
are listed in Listing~\ref{lst:focus}. \CI{sdsFocus} allows the programmer to
fix a parametric lens value. \CI{sdsLens} is a kind of \CI{mapReadWrite}
including access to the parametric lens value. This allows the creation of
for example \glspl{SDS} that only read and write to parts of the original
\gls{SDS}.

\begin{lstlisting}[label={lst:focus},
	caption={Parametric lens functions}]
sdsFocus :: p (RWShared p r w) -> RWShared p` r w | iTask p

:: SDSNotifyPred p :== p -> Bool

:: SDSLensRead p r rs     = SDSRead        (p -> rs -> MaybeError TaskException r)
                          | SDSReadConst   (p -> r)
:: SDSLensWrite p w rs ws = SDSWrite       (p -> rs -> w -> MaybeError TaskException (Maybe ws))
                          | SDSWriteConst  (p -> w -> MaybeError TaskException (Maybe ws))
:: SDSLensNotify p w rs   = SDSNotify      (p -> rs -> w -> SDSNotifyPred p)
                          | SDSNotifyConst (p -> w -> SDSNotifyPred p)

sdsLens :: String (p -> ps) (SDSLensRead p r rs) (SDSLensWrite p w rs ws) (SDSLensNotify p w rs)
	(RWShared ps rs ws) -> RWShared p r w | iTask ps
\end{lstlisting}
