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 \todo{check and refine}
  71 \Glspl{Task} can be combined using so called \gls{Task}-combinators.
  72 Combinators describe relations between \glspl{Task}. \Glspl{Task} can be
  73 combined in parallel, sequenced and their result values can be converted to
  74 \glspl{SDS}. Moreover, a very important combinator is the step combinator which
  75 starts a new task according to specified predicates on the \CI{TaskValue}.
  76 Type signatures of the basic combinators are shown in
  77 Listing~\ref{lst:combinators}.
  78
  79 \begin{itemize}
  80         \item Step:
  81
  82                 The step combinator is used to start \glspl{Task} when a predicate on
  83                 the \CI{TaskValue} holds or an action has taken place. The bind
  84                 operator can be written as a step combinator.
  85                 \begin{lstlisting}[language=Clean]
  86 (>>=) infixl 1 :: (Task a) (a -> (Task b)) -> (Task b) | iTask a & iTask b
  87 (>>=) ta f = ta >>* [OnAction "Continue" onValue, OnValue onStable]
  88     where
  89         onValue (Value a _)     = Just (f a)
  90         onValue _               = Nothing
  91
  92         onStable (Value a True) = Just (f a)
  93         onStable _              = Nothing
  94                 \end{lstlisting}
  95         \item Parallel:
  96
  97                 The parallel combinator allows for concurrent \glspl{Task}. The
  98                 \glspl{Task} combined with these operators will appear at the same time
  99                 in the web browser of the user and the results are combined as the type
 100                 dictates.
 101 \end{itemize}
 102
 103 \begin{lstlisting}[%
 104         caption={\Gls{Task}-combinators},label={lst:combinators}]
 105 //Step combinator
 106 (>>*)  infixl 1 :: (Task a) [TaskCont a (Task b)] -> Task b     | iTask a & iTask b
 107 (>>=)  infixl 1 :: (Task a) (a -> Task b)         -> Task b   | iTask a & iTask b
 108 :: TaskCont a b
 109         =     OnValue             ((TaskValue a)  -> Maybe b)
 110         |     OnAction    Action  ((TaskValue a)  -> Maybe b)
 111         | E.e: OnException         (e              -> b)       & iTask e
 112         |     OnAllExceptions     (String         -> b)
 113 :: Action = Action String
 114
 115 //Parallel combinators
 116 (-||-) infixr 3 :: (Task a) (Task a)              -> Task a     | iTask a
 117 (||-)  infixr 3 :: (Task a) (Task b)              -> Task b     | iTask a & iTask b
 118 (-||)  infixl 3 :: (Task a) (Task b)              -> Task a     | iTask a & iTask b
 119 (-&&-) infixr 4 :: (Task a) (Task b)              -> Task (a,b) | iTask a & iTask b
 120 \end{lstlisting}
 121
 122 \section{Shared Data Sources}
 123 \Glspl{SDS} are an abstraction over resources that are available in the world
 124 or in the \gls{iTasks} system. The shared data can be a file on disk, it can be
 125 the time, a random integer or just some data stored in memory. The actual
 126 \gls{SDS} is just a record containing functions on how to read and write the
 127 source. In these functions the \CI{*IWorld} which in turn contains the real
 128 program \CI{*World}. Accessing the outside world is required for interacting
 129 with it and thus the functions can access files on disk, raw memory, other
 130 shares and combine shares.
 131
 132 The basic operations for \glspl{SDS} are get, set and update. The signatures
 133 for these functions are shown in Listing~\ref{lst:shares}. By default, all
 134 shares are files containing a \gls{JSON} encoded version of the object and thus
 135 are persistent between restarts of the program. Library functions for shares
 136 residing in memory are available as well. The three main operations on shares
 137 are atomic in the sense that during reading no other tasks are executed.
 138
 139 The basic type for \glspl{SDS} has three \todo{parametric
 140 lenses}\cite{domoszlai_parametric_2014}.
 141
 142 \begin{lstlisting}[%
 143         label={lst:shares},caption={\Gls{SDS} functions}]
 144 :: RWShared p r w = ...
 145 :: ReadWriteShared r w :== RWShared () r w
 146 :: ROShared p r :== RWShared p () r
 147 :: ReadOnlyShared r :== ROShared () r
 148
 149 :: Shared r :== ReadWriteShared r r
 150
 151 get ::          (ReadWriteShared r w)           -> Task r | iTask r
 152 set :: w        (ReadWriteShared r w)           -> Task w | iTask w
 153 upd :: (r -> w) (ReadWriteShared r w)           -> Task w | iTask r & iTask w
 154
 155 sharedStore :: String a -> Shared a | JSONEncode{|*|}, JSONDecode{|*|}
 156 \end{lstlisting}