\section{iTasks}
-\gls{TOP} is a modern recent programming paradigm implemented as
+\gls{TOP} is a novel programming paradigm implemented as
\gls{iTasks}~\cite{achten_introduction_2015} in the pure lazy functional
-language \gls{Clean}~\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a
+language \gls{Clean}~\cite{brus_cleanlanguage_1987}. \gls{iTasks} is an
\gls{EDSL} to model workflow tasks in the broadest sense. A \gls{Task} is just
-a function that --- given some state --- returns the observable \CI{TaskValue}. The
-\CI{TaskValue} of a \CI{Task} can have different states. Not all state
+a function that --- given some state --- returns the observable \CI{TaskValue}.
+The \CI{TaskValue} of a \CI{Task} can have different states. Not all state
transitions are possible as shown in Figure~\ref{fig:taskvalue}. Once a value
-is stable it can never become unstable again. Stability is often reached
-by pressing a confirmation button. \glspl{Task} yielding a constant value are
+is stable it can never become unstable again. Stability is often reached by
+pressing a confirmation button. \glspl{Task} yielding a constant value are
immediately stable.
A simple \gls{iTasks} example illustrating the route to stability of a
user interface in Figure~\ref{fig:taskex1},~\ref{fig:taskex2}
and~\ref{fig:taskex3}. The \CI{TaskValue} of the \gls{Task} is in the first
image in the \CI{NoValue} state, the second image does not have all the fields
-filled in and therefore the \CI{TaskValue} remains \CI{Unstable}. In the third
+filled in and therefore the \CI{TaskValue} remains \CI{NoValue}. In the third
image all fields are entered and the \CI{TaskValue} transitions to the
\CI{Unstable} state. When the user presses \emph{Continue} the value becomes
\CI{Stable} and cannot be changed any further.
For a type to be suitable, it must have instances for a collection of generic
functions that is captured in the class \CI{iTask}. Basic types have
-specialization instances for these functions and show an according interface.
-Generated interfaces can be modified with decoration operators.
+specialization instances for these functions and show an interface accordingly.
+Derived interfaces can be modified with decoration operators or specializations
+can be created.
\section{Combinators}
\Glspl{Task} can be combined using so called \gls{Task}-combinators.
-Combinators describe relations between \glspl{Task}. \Glspl{Task} can be
-combined in parallel, sequenced and their result values can be converted to
-\glspl{SDS}. Moreover, a very important combinator is the step combinator which
-starts a new \gls{Task} according to specified predicates on the
-\CI{TaskValue}. Type signatures of the basic combinators are shown in
-Listing~\ref{lst:combinators}.
-
-\begin{itemize}
- \item Step:
-
- The step combinator is used to start \glspl{Task} when a predicate on
- the \CI{TaskValue} holds or an action has taken place. The bind
- operator can be written as a step combinator.
- \begin{lstlisting}[language=Clean]
-(>>=) infixl 1 :: (Task a) (a -> (Task b)) -> (Task b) | iTask a & iTask b
-(>>=) ta f = ta >>* [OnAction "Continue" onValue, OnValue onStable]
- where
- onValue (Value a _) = Just (f a)
- onValue _ = Nothing
-
- onStable (Value a True) = Just (f a)
- onStable _ = Nothing
- \end{lstlisting}
- \item Parallel:
-
- The parallel combinator allows for concurrent \glspl{Task}. The
- \glspl{Task} combined with these operators will appear at the same time
- in the web browser of the user and the results are combined as the type
- dictates.
-\end{itemize}
+Combinators describe relations between \glspl{Task}. There are only two basic
+types of combinators; parallel and sequence. All other combinators are
+derived from the basic combinators. Type signatures of simplified versions of
+the basic combinators and their derivations are given in
+Listing~\ref{lst:combinators}
\begin{lstlisting}[%
caption={\Gls{Task}-combinators},label={lst:combinators}]
//Step combinator
-(>>*) infixl 1 :: (Task a) [TaskCont a (Task b)] -> Task b | iTask a & iTask b
(>>=) infixl 1 :: (Task a) (a -> Task b) -> Task b | iTask a & iTask b
+(>>*) infixl 1 :: (Task a) [TaskCont a (Task b)] -> Task b | iTask a & iTask b
:: TaskCont a b
= OnValue ((TaskValue a) -> Maybe b)
| OnAction Action ((TaskValue a) -> Maybe b)
(-&&-) infixr 4 :: (Task a) (Task b) -> Task (a,b) | iTask a & iTask b
\end{lstlisting}
+\paragraph{Sequence:}
+The implementation for the sequence combinator is called the
+\CI{step} (\CI{>>*}). This combinator runs the left-hand \gls{Task} and
+starts the right-hand side when a certain predicate holds. Predicates
+can be propositions about the \CI{TaskValue}, user actions from within
+the web browser or a thrown exception. The familiar
+bind-combinator is an example of a sequence combinator. This combinator
+runs the left-hand side and continues to the right-hand \gls{Task} if
+there is an \CI{UnStable} value and the user presses continue or when
+the value is \CI{Stable}. The combinator could have been implemented
+as follows:
+\begin{lstlisting}[language=Clean]
+(>>=) infixl 1 :: (Task a) (a -> (Task b)) -> (Task b) | iTask a & iTask b
+(>>=) ta f = ta >>* [OnAction "Continue" onValue, OnValue onStable]
+ where
+ onValue (Value a _) = Just (f a)
+ onValue _ = Nothing
+
+ onStable (Value a True) = Just (f a)
+ onStable _ = Nothing
+\end{lstlisting}
+
+\paragraph{Parallel:}
+The parallel combinator allows for concurrent \glspl{Task}. The
+\glspl{Task} combined with these operators will appear at the same time
+in the web browser of the user and the results are combined as the type
+dictates. All parallel combinators used are derived from the basic parallel
+combinator that is very complex and only used internally.
+
\section{Shared Data Sources}
\Glspl{SDS} are an abstraction over resources that are available in the world
or in the \gls{iTasks} system. The shared data can be a file on disk, the
system time, a random integer or just some data stored in memory. The actual
\gls{SDS} is just a record containing functions on how to read and write the
source. In these functions the \CI{*IWorld} --- which in turn contains the real
-program \CI{*World} --- is available. Accessing the outside world is required
-for interacting with it and thus the functions can access files on disk, raw
+\CI{*World} --- is available. Accessing the outside world is required for
+interacting with it and thus the functions can access files on disk, raw
memory, other \glspl{SDS} and hardware.
The basic operations for \glspl{SDS} are get, set and update. The signatures
shares are atomic in the sense that during reading no other \glspl{Task} are
executed. The system provides useful functions to transform, map and combine
\glspl{SDS} using combinators. The system also provides functionality to
-inspect the value of a \gls{SDS} and act upon a change. \Glspl{Task} waiting on
-a \gls{SDS} to change are notified when needed. This results in low resource
+inspect the value of an \gls{SDS} and act upon a change. \Glspl{Task} waiting on
+an \gls{SDS} to change are notified when needed. This results in low resource
usage because \glspl{Task} are never constantly inspecting \gls{SDS} values but
are notified.
resource are notified of the update. However, it may be the case that
\glspl{Task} were only looking at parts of the structure that was not updated.
To solve this problem, parametric lenses were
-introduced~~\cite{domoszlai_parametric_2014}.
+introduced~\cite{domoszlai_parametric_2014}.
-Parametric lenses add a type variable to the \gls{SDS} that is in the current
-library functions fixed to the void type (i.e. \CI{()}). When a \gls{SDS}
+Parametric lenses add a type variable to the \gls{SDS}. This type variable is
+fixed to the void type (i.e. \CI{()}) in the given functions. When an \gls{SDS}
executes a write operation, it also provides the system with a notification
predicate. This notification predicate is a function \CI{p -> Bool} where
\CI{p} is the parametric lens type. This allows programmers to create a big
when the structure is updated. The type of the parametric lens is the key in
the map.
-Functionality for setting parameters is added in the system. The most important
-function is the \CI{sdsFocus} function. This function is listed in
-Listing~\ref{lst:focus} and allows the programmer to fix the parametric lens to
-a specific value.
+Functionality for setting parameters is available in the system. The most
+important functions are the \CI{sdsFocus} and the \CI{sdsLens} function. These
+functions are listed in Listing~\ref{lst:focus}. \CI{sdsFocus} allows the
+programmer to fix a parametric lens value. \CI{sdsLens} is a kind of
+\CI{mapReadWrite} including access to the parametric lens value. This allows
+the creation of, for example, \glspl{SDS} that only read and write to parts of
+the original \gls{SDS}.
\begin{lstlisting}[label={lst:focus},
caption={Parametric lens functions}]
sdsFocus :: p (RWShared p r w) -> RWShared p` r w | iTask p
+
+:: SDSNotifyPred p :== p -> Bool
+
+:: SDSLensRead p r rs = SDSRead (p -> rs -> MaybeError TaskException r)
+ | SDSReadConst (p -> r)
+:: SDSLensWrite p w rs ws = SDSWrite (p -> rs -> w -> MaybeError TaskException (Maybe ws))
+ | SDSWriteConst (p -> w -> MaybeError TaskException (Maybe ws))
+:: SDSLensNotify p w rs = SDSNotify (p -> rs -> w -> SDSNotifyPred p)
+ | SDSNotifyConst (p -> w -> SDSNotifyPred p)
+
+sdsLens :: String (p -> ps) (SDSLensRead p r rs) (SDSLensWrite p w rs ws) (SDSLensNotify p w rs)
+ (RWShared ps rs ws) -> RWShared p r w | iTask ps
\end{lstlisting}
repositories / msc-thesis1617.git / blobdiff