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
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.
26 \includegraphics[width=
.5\linewidth]{fig-taskvalue
}
27 \caption{The states of a
\CI{TaskValue
}}\label{fig:taskvalue
}
30 \begin{lstlisting
}[language=Clean,label=
{lst:taskex
},
%
31 caption=
{An example
\gls{Task
} for entering a name
}]
32 :: Name =
{ firstname :: String
36 derive class iTask Name
38 enterInformation :: String
[EnterOption m
] -> (Task m) | iTask m
40 enterName :: Task Name
41 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 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.
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
}.
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
]
89 onValue (Value a _) = Just (f a)
92 onStable (Value a True) = Just (f a)
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
103 \begin{lstlisting
}[language=Clean,
%
104 caption=
{\Gls{Task
}-combinators
},label=
{lst:combinators
}]
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
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
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
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{*World
} is available and therefore it can
128 interact with the outside world. The
\CI{*IWorld
} is also available and
129 therefore the functions can also access other shares, possibly combining them.
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
}. All of the
133 operations are atomic in the sense that during reading no other tasks are
137 language=Clean,label=
{lst:shares
},caption=
{\Gls{SDS
} functions
}]
138 get :: (ReadWriteShared r w) -> Task r | iTask r
139 set :: w (ReadWriteShared r w) -> Task w | iTask w
140 upd :: (r -> w) (ReadWriteShared r w) -> Task w | iTask r & iTask w