+++ /dev/null
-\section{iTasks}
-\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 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
-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
-immediately stable.
-
-A simple \gls{iTasks} example illustrating the route to stability of a
-\gls{Task} in which the user has to enter a full name is shown in
-Listing~\ref{lst:taskex}. The code is accompanied by screenshots showing the
-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{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.
-
-\begin{figure}[H]
- \centering
- \includegraphics[width=.5\linewidth]{fig-taskvalue}
- \caption{The states of a \CI{TaskValue}}\label{fig:taskvalue}
-\end{figure}
-
-\begin{lstlisting}[label={lst:taskex},%
- caption={An example \gls{Task} for entering a name}]
-:: Name = { firstname :: String
- , lastname :: String
- }
-
-derive class iTask Name
-
-enterInformation :: String [EnterOption m] -> (Task m) | iTask m
-
-enterName :: Task Name
-enterName = enterInformation "Enter your name" []
-\end{lstlisting}
-
-\begin{figure}[H]
- \centering
- \begin{subfigure}{.25\textwidth}
- \centering
- \includegraphics[width=.9\linewidth]{taskex1}
- \caption{Initial interface}\label{fig:taskex1}
- \end{subfigure}
- \begin{subfigure}{.25\textwidth}
- \centering
- \includegraphics[width=.9\linewidth]{taskex2}
- \caption{Incomplete entrance}\label{fig:taskex2}
- \end{subfigure}
- \begin{subfigure}{.25\textwidth}
- \centering
- \includegraphics[width=.9\linewidth]{taskex3}
- \caption{Complete entry}\label{fig:taskex3}
- \end{subfigure}
- \caption{Example of a generated user interface}
-\end{figure}
-
-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 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}. 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) (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)
- | E.e: OnException (e -> b) & iTask e
- | OnAllExceptions (String -> b)
-:: Action = Action String
-
-//Parallel combinators
-(-||-) infixr 3 :: (Task a) (Task a) -> Task a | iTask a
-(||-) infixr 3 :: (Task a) (Task b) -> Task b | iTask a & iTask b
-(-||) infixl 3 :: (Task a) (Task b) -> Task a | iTask a & iTask 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
-\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
-for these functions are shown in Listing~\ref{lst:shares}. By default, all
-\glspl{SDS} are files containing a \gls{JSON} encoded version of the object and
-thus are persistent between restarts of the program. Library functions for
-shares residing in memory are available as well. The three main operations on
-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 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.
-
-\begin{lstlisting}[%
- label={lst:shares},caption={\Gls{SDS} functions}]
-:: RWShared p r w = ...
-:: ReadWriteShared r w :== RWShared () r w
-:: ROShared p r :== RWShared p () r
-:: ReadOnlyShared r :== ROShared () r
-
-:: Shared r :== ReadWriteShared r r
-
-get :: (ReadWriteShared r w) -> Task r | iTask r
-set :: w (ReadWriteShared r w) -> Task w | iTask w
-upd :: (r -> w) (ReadWriteShared r w) -> Task w | iTask r & iTask w
-
-sharedStore :: String a -> Shared a | JSONEncode{|*|}, JSONDecode{|*|}
-\end{lstlisting}
-
-\section{Parametric Lenses}
-\Glspl{SDS} can contain complex data structures such as lists, trees and even
-resources in the outside world. Sometimes, an update action only updates a part
-of the resource. When this happens, all waiting \glspl{Task} looking at the
-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}.
-
-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
-\gls{SDS}, and have \glspl{Task} only look at parts of the big \gls{SDS}. This
-technique is used in the current system in memory shares. The \CI{IWorld}
-contains a map that is accessible through an \gls{SDS}. While all data is
-stored in the map, only \glspl{Task} looking at a specific entry are notified
-when the structure is updated. The type of the parametric lens is the key in
-the map.
-
-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