share details

[msc-thesis1617.git] / methods.top.tex

diff --git a/methods.top.tex b/methods.top.tex
index c05165a..ec330c9 100644 (file)
--- a/methods.top.tex
+++ b/methods.top.tex
@@ -1,8 +1,8 @@
 \section{iTasks}
 \section{iTasks}

-\gls{TOP} is a recent programming paradigm implemented as
+\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{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
+\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
 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


@@ -27,7 +27,7 @@ image all fields are entered and the \CI{TaskValue} transitions to the
        \caption{The states of a \CI{TaskValue}}\label{fig:taskvalue}
 \end{figure}
 
        \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
        caption={An example \gls{Task} for entering a name}]
 :: Name = { firstname :: String
           , lastname  :: String


@@ -42,6 +42,7 @@ enterName = enterInformation "Enter your name" []
 \end{lstlisting}
 
 \begin{figure}[H]
 \end{lstlisting}
 
 \begin{figure}[H]

+       \centering

        \begin{subfigure}{.25\textwidth}
                \centering
                \includegraphics[width=.9\linewidth]{taskex1}
        \begin{subfigure}{.25\textwidth}
                \centering
                \includegraphics[width=.9\linewidth]{taskex1}


@@ -60,8 +61,8 @@ enterName = enterInformation "Enter your name" []
        \caption{Example of a generated user interface}
 \end{figure}
 
        \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.
 
 specialization instances for these functions and show an according interface.
 Generated interfaces can be modified with decoration operators.
 


@@ -98,7 +99,7 @@ Listing~\ref{lst:combinators}.
                dictates.
 \end{itemize}
 
                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
        caption={\Gls{Task}-combinators},label={lst:combinators}]
 //Step combinator
 (>>*)  infixl 1 :: (Task a) [TaskCont a (Task b)] -> Task b     | iTask a & iTask b


@@ -117,24 +118,70 @@ Listing~\ref{lst:combinators}.
 (-&&-) infixr 4 :: (Task a) (Task b)              -> Task (a,b) | iTask a & iTask b
 \end{lstlisting}
 
 (-&&-) infixr 4 :: (Task a) (Task b)              -> Task (a,b) | iTask a & iTask b
 \end{lstlisting}
 

-\section{\acrlongpl{SDS}}
+\section{Shared Data Sources}

 \Glspl{SDS} are an abstraction over resources that are available in the world
 \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, it can be
-the time, a random integer or just some data stored in memory. The actual
+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
 \gls{SDS} is just a record containing functions on how to read and write the

-source. In these functions the \CI{*World} is available and therefore it can
-interact with the outside world. The \CI{*IWorld} is also available and
-therefore the functions can also access other shares, possibly combining them.
+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
 
 The basic operations for \glspl{SDS} are get, set and update. The signatures

-for these functions are shown in Listing~\ref{lst:shares}. All of the
-operations are atomic in the sense that during reading no other tasks are
-executed.
+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}[%
 
 \begin{lstlisting}[%

-       language=Clean,label={lst:shares},caption={\Gls{SDS} functions}]
+       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
 
 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}
 \end{lstlisting}