1 \section{\acrlong{TOP
}}
2 \subsection{\gls{iTasks
}}
3 \gls{TOP
} is a recent programming paradigm implemented as
4 \gls{iTasks
}\cite{achten_introduction_2015
} in the pure lazy functional
5 language
\gls{Clean
}\cite{brus_cleanlanguage_1987
}.
\gls{iTasks
} is a
6 \gls{EDSL
} to model workflow tasks in the broadest sense. A
\CI{Task
} is just
7 a function that, given some state, returns the observable
\CI{TaskValue
}. The
8 \CI{TaskValue
} of a
\CI{Task
} can have different states. Not all state
9 transitions are possible as shown in Figure~
\ref{fig:taskvalue
}. Once a value
10 is stable it can never become unstable again. Stability is often reached
11 by pressing a confirmation button.
\glspl{Task
} yielding a constant value are
14 A simple
\gls{iTasks
} example illustrating the route to stability of a
15 \gls{Task
} in which the user has to enter a full name is shown in
16 Listing~
\ref{lst:taskex
}. The code is accompanied by screenshots showing the
17 user interface in Figure~
\ref{fig:taskex1
},~
\ref{fig:taskex2
}
18 and~
\ref{fig:taskex3
}. The
\CI{TaskValue
} of the
\gls{Task
} is in the first
19 image in the
\CI{NoValue
} state, the second image does not have all the fields
20 filled in and therefore the
\CI{TaskValue
} remains
\CI{Unstable
}. In the third
21 image all fields are entered and the
\CI{TaskValue
} transitions to the
22 \CI{Unstable
} state. When the user presses
\emph{Continue
} the value becomes
23 \CI{Stable
} and can not be changed any further.
27 \includegraphics[width=
.5\linewidth]{fig-taskvalue
}
28 \caption{The states of a
\CI{TaskValue
}}\label{fig:taskvalue
}
31 \begin{lstlisting
}[language=Clean,label=
{lst:taskex
},
%
32 caption=
{An example
\gls{Task
} for entering a name
}]
33 :: Name =
{ firstname :: String
37 derive class iTask Name
39 enterInformation :: String
[EnterOption m
] -> (Task m) | iTask m
41 enterName :: Task Name
42 enterName = enterInformation "Enter your name"
[]
46 \begin{subfigure
}{.25\textwidth}
48 \includegraphics[width=
.9\linewidth]{taskex1
}
49 \caption{Initial interface
}\label{fig:taskex1
}
51 \begin{subfigure
}{.25\textwidth}
53 \includegraphics[width=
.9\linewidth]{taskex2
}
54 \caption{Incomplete entrance
}\label{fig:taskex2
}
56 \begin{subfigure
}{.25\textwidth}
58 \includegraphics[width=
.9\linewidth]{taskex3
}
59 \caption{Complete entry
}\label{fig:taskex3
}
61 \caption{Example of a generated user interface
}
64 For a type to be suitable it must have instances for a collection of generic
65 functions that are captured in the class
\CI{iTask
}. Basic types have
66 specialization instances for these functions and show an according interface.
67 Generated interfaces can be modified with decoration operators.
69 \subsection{Combinators
}
70 \Glspl{Task
} can be combined using so called
\gls{Task
}-combinators.
71 Combinators describe relations between
\glspl{Task
}.
\Glspl{Task
} can be
72 combined in parallel, sequenced and their result values can be converted to
73 \glspl{SDS
}. Moreover, a very important combinator is the step combinator that
74 starts a new task according to the
\CI{TaskValue
}. The type signatures of the
75 basic combinators are shown in Listing~
\ref{lst:combinators
}.
80 The step combinator is used to start
\glspl{Task
} when a predicate on
81 the
\CI{TaskValue
} holds or an action has been taken place. The bind
82 operator can be written as a step combinator.
83 \begin{lstlisting
}[language=Clean
]
84 (>>=) infixl
1 :: (Task a) (a -> (Task b)) -> (Task b) | iTask a & iTask b
85 (>>=) ta f = ta >>*
[OnAction "Continue" onValue, OnValue onStable
]
87 onValue (Value a _) = Just (f a)
90 onStable (Value a True) = Just (f a)
95 The parallel combinator allows for concurrent
\glspl{Task
}. The
96 \glspl{Task
} combined with these operators will appear at the same time
97 in the web browser of the user and the results are combined as the type
101 \begin{lstlisting
}[language=Clean,
%
102 caption=
{\Gls{Task
}-combinators
},label=
{lst:combinators
}]
104 (>>*) infixl
1 :: (Task a)
[TaskCont a (Task b)
] -> Task b | iTask a & iTask b
105 (>>=) infixl
1 :: (Task a) (a -> Task b) -> Task b | iTask a & iTask b
107 = OnValue ((TaskValue a) -> Maybe b)
108 | OnAction Action ((TaskValue a) -> Maybe b)
109 | E.e: OnException (e -> b) & iTask e
110 | OnAllExceptions (String -> b)
111 :: Action = Action String
113 //Parallel combinators
114 (-||-) infixr
3 :: (Task a) (Task a) -> Task a | iTask a
115 (||-) infixr
3 :: (Task a) (Task b) -> Task b | iTask a & iTask b
116 (-||) infixl
3 :: (Task a) (Task b) -> Task a | iTask a & iTask b
117 (-&&-) infixr
4 :: (Task a) (Task b) -> Task (a,b) | iTask a & iTask b
120 \subsection{\acrlongpl{SDS
}}
121 \Glspl{SDS
} are an abstraction over resources that are available in the world
122 or in the
\gls{iTasks
} system. The shared data can be a file on disk, it can be
123 the time, a random integer or just some data stored in memory. The actual
124 \gls{SDS
} is just a record containing functions on how to read and write the
125 source. In these functions the
\CI{*World
} is available and therefore it can
126 interact with the outside world. The
\CI{*IWorld
} is also available and
127 therefore the functions can also access other shares, possibly combining them.
129 The basic operations for
\glspl{SDS
} are get, set and update. The signatures
130 for these functions are shown in Listing~
\ref{lst:shares
}. All of the
131 operations are atomic in the sense that during reading no other tasks are
135 language=Clean,label=
{lst:shares
},caption=
{\Gls{SDS
} functions
}]
136 get :: (ReadWriteShared r w) -> Task r | iTask r
137 set :: w (ReadWriteShared r w) -> Task w | iTask w
138 upd :: (r -> w) (ReadWriteShared r w) -> Task w | iTask r & iTask w