-\section{\acrlong{TOP}}
-\subsection{\gls{iTasks}}
-\gls{TOP} is a recent programming paradigm implemented as
+\section{iTasks}
+\gls{TOP} is a modern recent 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
-\gls{EDSL} to model workflow tasks in the broadest sense. A \CI{Task} is just
-a function that, given some state, returns the observable \CI{TaskValue}. The
+\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
filled in and therefore the \CI{TaskValue} remains \CI{Unstable}. 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 can not be changed any further.
+\CI{Stable} and cannot be changed any further.
\begin{figure}[H]
\centering
\caption{The states of a \CI{TaskValue}}\label{fig:taskvalue}
\end{figure}
-\begin{lstlisting}[language=Clean,label={lst:taskex},%
+\begin{lstlisting}[label={lst:taskex},%
caption={An example \gls{Task} for entering a name}]
:: Name = { firstname :: String
, lastname :: String
\end{lstlisting}
\begin{figure}[H]
+ \centering
\begin{subfigure}{.25\textwidth}
\centering
\includegraphics[width=.9\linewidth]{taskex1}
\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 are captured in the class \CI{iTask}. Basic types have
+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.
-\subsection{Combinators}
+\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 that
-starts a new task according to the \CI{TaskValue}. The type signatures of the
-basic combinators are shown in Listing~\ref{lst:combinators}.
+\glspl{SDS}. Moreover, a very important combinator is the step combinator which
+starts a new 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 been taken place. The bind
+ 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
onValue (Value a _) = Just (f a)
onValue _ = Nothing
- onStable (Value a True) = Just (f a)
- onStable _ = Nothing
+ onStable (Value a True) = Just (f a)
+ onStable _ = Nothing
\end{lstlisting}
\item Parallel:
dictates.
\end{itemize}
-\begin{lstlisting}[language=Clean,%
+\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
(-&&-) infixr 4 :: (Task a) (Task b) -> Task (a,b) | iTask a & iTask b
\end{lstlisting}
-\subsection{\acrlongpl{SDS}}
+\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
+memory, other shares 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
+shares 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 tasks 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 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} where 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} that is in the current
+library functions fixed to \CI{()}. When a \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 share, and have
+\glspl{Task} only look at parts of the big share. 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 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 value.
+
+\begin{lstlisting}[label={lst:focus},
+ caption={Parametric lens functions}]
+sdsFocus :: p (RWShared p r w) -> RWShared p` r w | iTask p
+\end{lstlisting}
repositories / msc-thesis1617.git / blobdiff