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 \gls{Task} according to specified predicates on the
  75 \CI{TaskValue}.  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 \glspl{SDS} 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 \glspl{SDS} are files containing a \gls{JSON} encoded version of the object and
 134 thus are persistent between restarts of the program. Library functions for
 135 shares residing in memory are available as well. The three main operations on
 136 shares are atomic in the sense that during reading no other \glspl{Task} are
 137 executed.  The system provides useful functions to transform, map and combine
 138 \glspl{SDS} using combinators. The system also provides functionality to
 139 inspect the value of a \gls{SDS} and act upon a change. \Glspl{Task} waiting on
 140 a \gls{SDS} to change are notified when needed. This results in low resource
 141 usage because \glspl{Task} are never constantly inspecting \gls{SDS} values but
 142 are notified.
 143
 144 \begin{lstlisting}[%
 145         label={lst:shares},caption={\Gls{SDS} functions}]
 146 :: RWShared p r w = ...
 147 :: ReadWriteShared r w :== RWShared () r w
 148 :: ROShared p r :== RWShared p () r
 149 :: ReadOnlyShared r :== ROShared () r
 150
 151 :: Shared r :== ReadWriteShared r r
 152
 153 get ::          (ReadWriteShared r w)           -> Task r | iTask r
 154 set :: w        (ReadWriteShared r w)           -> Task w | iTask w
 155 upd :: (r -> w) (ReadWriteShared r w)           -> Task w | iTask r & iTask w
 156
 157 sharedStore :: String a -> Shared a | JSONEncode{|*|}, JSONDecode{|*|}
 158 \end{lstlisting}
 159
 160 \section{Parametric Lenses}
 161 \Glspl{SDS} can contain complex data structures such as lists, trees and even
 162 resources in the outside world. Sometimes, an update action only updates a part
 163 of the resource. When this happens, all waiting \glspl{Task} looking at the
 164 resource are notified of the update. However, it may be the case that
 165 \glspl{Task} were only looking at parts of the structure that was not updated.
 166 To solve this problem, parametric lenses were
 167 introduced~\cite{domoszlai_parametric_2014}.
 168
 169 Parametric lenses add a type variable to the \gls{SDS} that is in the current
 170 library functions fixed to the void type (i.e. \CI{()}). When a \gls{SDS}
 171 executes a write operation, it also provides the system with a notification
 172 predicate. This notification predicate is a function \CI{p -> Bool} where
 173 \CI{p} is the parametric lens type. This allows programmers to create a big
 174 \gls{SDS}, and have \glspl{Task} only look at parts of the big \gls{SDS}. This
 175 technique is used in the current system in memory shares. The \CI{IWorld}
 176 contains a map that is accessible through a \gls{SDS}. While all data is
 177 stored in the map, only \glspl{Task} looking at a specific entry are notified
 178 when the structure is updated. The type of the parametric lens is the key in
 179 the map.
 180
 181 Functionality for setting parameters is added in the system. The most important
 182 functions are the \CI{sdsFocus} and the \CI{sdsLens} function. These functions
 183 are listed in Listing~\ref{lst:focus}. \CI{sdsFocus} allows the programmer to
 184 fix a parametric lens value. \CI{sdsLens} is a kind of \CI{mapReadWrite}
 185 including access to the parametric lens value. This allows the creation of
 186 for example \glspl{SDS} that only read and write to parts of the original
 187 \gls{SDS}.
 188
 189 \begin{lstlisting}[label={lst:focus},
 190         caption={Parametric lens functions}]
 191 sdsFocus :: p (RWShared p r w) -> RWShared p` r w | iTask p
 192
 193 :: SDSNotifyPred p :== p -> Bool
 194
 195 :: SDSLensRead p r rs     = SDSRead        (p -> rs -> MaybeError TaskException r)
 196                           | SDSReadConst   (p -> r)
 197 :: SDSLensWrite p w rs ws = SDSWrite       (p -> rs -> w -> MaybeError TaskException (Maybe ws))
 198                           | SDSWriteConst  (p -> w -> MaybeError TaskException (Maybe ws))
 199 :: SDSLensNotify p w rs   = SDSNotify      (p -> rs -> w -> SDSNotifyPred p)
 200                           | SDSNotifyConst (p -> w -> SDSNotifyPred p)
 201
 202 sdsLens :: String (p -> ps) (SDSLensRead p r rs) (SDSLensWrite p w rs ws) (SDSLensNotify p w rs)
 203         (RWShared ps rs ws) -> RWShared p r w | iTask ps
 204 \end{lstlisting}