methods.top.tex

   1 \section{iTasks}
   2 \gls{TOP} is a modern recent programming paradigm implemented as
   3 \gls{iTasks}\cite{achten_introduction_2015} in the pure lazy functional
   4 language \gls{Clean}\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a
   5 \gls{EDSL} to model workflow tasks in the broadest sense. A \gls{Task} is just
   6 a function that --- given some state --- returns the observable \CI{TaskValue}. The
   7 \CI{TaskValue} of a \CI{Task} can have different states. Not all state
   8 transitions are possible as shown in Figure~\ref{fig:taskvalue}. Once a value
   9 is stable it can never become unstable again. Stability is often reached
  10 by pressing a confirmation button. \glspl{Task} yielding a constant value are
  11 immediately stable.
  12
  13 A simple \gls{iTasks} example illustrating the route to stability of a
  14 \gls{Task} in which the user has to enter a full name is shown in
  15 Listing~\ref{lst:taskex}. The code is accompanied by screenshots showing the
  16 user interface in Figure~\ref{fig:taskex1},~\ref{fig:taskex2}
  17 and~\ref{fig:taskex3}. The \CI{TaskValue} of the \gls{Task} is in the first
  18 image in the \CI{NoValue} state, the second image does not have all the fields
  19 filled in and therefore the \CI{TaskValue} remains \CI{Unstable}. In the third
  20 image all fields are entered and the \CI{TaskValue} transitions to the
  21 \CI{Unstable} state. When the user presses \emph{Continue} the value becomes
  22 \CI{Stable} and cannot be changed any further.
  23
  24 \begin{figure}[H]
  25         \centering
  26         \includegraphics[width=.5\linewidth]{fig-taskvalue}
  27         \caption{The states of a \CI{TaskValue}}\label{fig:taskvalue}
  28 \end{figure}
  29
  30 \begin{lstlisting}[label={lst:taskex},%
  31         caption={An example \gls{Task} for entering a name}]
  32 :: Name = { firstname :: String
  33           , lastname  :: String
  34           }
  35
  36 derive class iTask Name
  37
  38 enterInformation :: String [EnterOption m] -> (Task m) | iTask m
  39
  40 enterName :: Task Name
  41 enterName = enterInformation "Enter your name" []
  42 \end{lstlisting}
  43
  44 \begin{figure}[H]
  45         \centering
  46         \begin{subfigure}{.25\textwidth}
  47                 \centering
  48                 \includegraphics[width=.9\linewidth]{taskex1}
  49                 \caption{Initial interface}\label{fig:taskex1}
  50         \end{subfigure}
  51         \begin{subfigure}{.25\textwidth}
  52                 \centering
  53                 \includegraphics[width=.9\linewidth]{taskex2}
  54                 \caption{Incomplete entrance}\label{fig:taskex2}
  55         \end{subfigure}
  56         \begin{subfigure}{.25\textwidth}
  57                 \centering
  58                 \includegraphics[width=.9\linewidth]{taskex3}
  59                 \caption{Complete entry}\label{fig:taskex3}
  60         \end{subfigure}
  61         \caption{Example of a generated user interface}
  62 \end{figure}
  63
  64 For a type to be suitable, it must have instances for a collection of generic
  65 functions that is 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.
  68
  69 \section{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 which
  74 starts a new task according to specified predicates on the \CI{TaskValue}.
  75 Type signatures of the basic combinators are shown in
  76 Listing~\ref{lst:combinators}.
  77
  78 \begin{itemize}
  79         \item Step:
  80
  81                 The step combinator is used to start \glspl{Task} when a predicate on
  82                 the \CI{TaskValue} holds or an action has taken place. The bind
  83                 operator can be written as a step combinator.
  84                 \begin{lstlisting}[language=Clean]
  85 (>>=) infixl 1 :: (Task a) (a -> (Task b)) -> (Task b) | iTask a & iTask b
  86 (>>=) ta f = ta >>* [OnAction "Continue" onValue, OnValue onStable]
  87     where
  88         onValue (Value a _)     = Just (f a)
  89         onValue _               = Nothing
  90
  91         onStable (Value a True) = Just (f a)
  92         onStable _              = Nothing
  93                 \end{lstlisting}
  94         \item Parallel:
  95
  96                 The parallel combinator allows for concurrent \glspl{Task}. The
  97                 \glspl{Task} combined with these operators will appear at the same time
  98                 in the web browser of the user and the results are combined as the type
  99                 dictates.
 100 \end{itemize}
 101
 102 \begin{lstlisting}[%
 103         caption={\Gls{Task}-combinators},label={lst:combinators}]
 104 //Step combinator
 105 (>>*)  infixl 1 :: (Task a) [TaskCont a (Task b)] -> Task b     | iTask a & iTask b
 106 (>>=)  infixl 1 :: (Task a) (a -> Task b)         -> Task b   | iTask a & iTask b
 107 :: TaskCont a b
 108         =     OnValue             ((TaskValue a)  -> Maybe b)
 109         |     OnAction    Action  ((TaskValue a)  -> Maybe b)
 110         | E.e: OnException         (e              -> b)       & iTask e
 111         |     OnAllExceptions     (String         -> b)
 112 :: Action = Action String
 113
 114 //Parallel combinators
 115 (-||-) infixr 3 :: (Task a) (Task a)              -> Task a     | iTask a
 116 (||-)  infixr 3 :: (Task a) (Task b)              -> Task b     | iTask a & iTask b
 117 (-||)  infixl 3 :: (Task a) (Task b)              -> Task a     | iTask a & iTask b
 118 (-&&-) infixr 4 :: (Task a) (Task b)              -> Task (a,b) | iTask a & iTask b
 119 \end{lstlisting}
 120
 121 \section{Shared Data Sources}
 122 \Glspl{SDS} are an abstraction over resources that are available in the world
 123 or in the \gls{iTasks} system. The shared data can be a file on disk, the
 124 system time, a random integer or just some data stored in memory. The actual
 125 \gls{SDS} is just a record containing functions on how to read and write the
 126 source. In these functions the \CI{*IWorld} --- which in turn contains the real
 127 program \CI{*World} --- is available. Accessing the outside world is required
 128 for interacting with it and thus the functions can access files on disk, raw
 129 memory, other shares and hardware.
 130
 131 The basic operations for \glspl{SDS} are get, set and update. The signatures
 132 for these functions are shown in Listing~\ref{lst:shares}. By default, all
 133 shares are files containing a \gls{JSON} encoded version of the object and thus
 134 are persistent between restarts of the program. Library functions for shares
 135 residing in memory are available as well. The three main operations on shares
 136 are atomic in the sense that during reading no other tasks are executed. The
 137 system provides useful functions to transform, map and combine \glspl{SDS}
 138 using combinators. The system also provides functionality to inspect the value
 139 of a \gls{SDS} and act upon a change. \Glspl{Task} waiting on a \gls{SDS} to
 140 change are notified when needed. This results in low resource usage because
 141 \glspl{Task} are never constantly inspecting \gls{SDS} values but are notified.
 142
 143 \begin{lstlisting}[%
 144         label={lst:shares},caption={\Gls{SDS} functions}]
 145 :: RWShared p r w = ...
 146 :: ReadWriteShared r w :== RWShared () r w
 147 :: ROShared p r :== RWShared p () r
 148 :: ReadOnlyShared r :== ROShared () r
 149
 150 :: Shared r :== ReadWriteShared r r
 151
 152 get ::          (ReadWriteShared r w)           -> Task r | iTask r
 153 set :: w        (ReadWriteShared r w)           -> Task w | iTask w
 154 upd :: (r -> w) (ReadWriteShared r w)           -> Task w | iTask r & iTask w
 155
 156 sharedStore :: String a -> Shared a | JSONEncode{|*|}, JSONDecode{|*|}
 157 \end{lstlisting}
 158
 159 \section{Parametric Lenses}
 160 \Glspl{SDS} can contain complex data structures such as lists, trees and even
 161 resources in the outside world. Sometimes, an update action only updates a part
 162 of the resource. When this happens, all waiting \glspl{Task} looking at the
 163 resource are notified of the update. However, it may be the case that
 164 \glspl{Task} where only looking at parts of the structure that was not updated.
 165 To solve this problem, parametric lenses were
 166 introduced~\cite{domoszlai_parametric_2014}.
 167
 168 Parametric lenses add a type variable to the \gls{SDS} that is in the current
 169 library functions fixed to \CI{()}. When a \gls{SDS} executes a write
 170 operation it also provides the system with a notification predicate. This
 171 notification predicate is a function \CI{p -> Bool} where \CI{p} is the
 172 parametric lens type. This allows programmers to create a big share, and have
 173 \glspl{Task} only look at parts of the big share. This technique is used in the
 174 current system in memory shares. The \CI{IWorld} contains a map that is
 175 accessible through an \gls{SDS}. While all data is stored in the map, only
 176 \glspl{Task} looking at a specific entry are notified when the structure is
 177 updated. The type of the parametric lens is the key in the map.
 178
 179 Functionality for setting parameters is added in the system. The most important
 180 function is the \CI{sdsFocus} function. This function is listed in
 181 Listing~\ref{lst:focus} and allows the programmer to fix the parametric lens to
 182 a value.
 183
 184 \begin{lstlisting}[label={lst:focus},
 185         caption={Parametric lens functions}]
 186 sdsFocus :: p (RWShared p r w) -> RWShared p` r w | iTask p
 187 \end{lstlisting}