X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=methods.top.tex;h=811e12a1c85df94705541c400588d98ef73e5880;hb=b8e0188d0d4b4f321259e036807b439c85753828;hp=52ed983bcd4f327dcbe64efe6894bb5e21f85b4c;hpb=b0fc85be57e369c5a04adaba4d6920a59d3d36e2;p=msc-thesis1617.git

diff --git a/methods.top.tex b/methods.top.tex
index 52ed983..811e12a 100644
--- a/methods.top.tex
+++ b/methods.top.tex
@@ -1,19 +1,25 @@
-\section{\acrlong{TOP}}
-\subsection{\gls{iTasks}}
-\gls{TOP} is a recent new 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
-\CI{TaskValue} of a \CI{Task} can have different states. Not all state
+\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
-has gone stable it can never become unstable again. Stability is often reached
-by pressing a confirmation button or for \glspl{Task} that offer a constant
-value. A simple example is shown in Listing~\ref{lst:taskex} accompanied with
-Figure~\ref{fig:taskex1},~\ref{fig:taskex2} and~\ref{fig:taskex3}. In this
-example the first image in is the \CI{NoValue} state, the second and third
-image are in the \CI{Unstable} state. When the user presses \emph{Continue} the
-value becomes \CI{Stable}.
+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{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 cannot be changed any further.
 
 \begin{figure}[H]
 	\centering
@@ -21,11 +27,11 @@ value becomes \CI{Stable}.
 	\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
-				  }
+:: Name = { firstname :: String
+          , lastname  :: String
+          }
 
 derive class iTask Name
 
@@ -36,6 +42,7 @@ enterName = enterInformation "Enter your name" []
 \end{lstlisting}
 
 \begin{figure}[H]
+	\centering
 	\begin{subfigure}{.25\textwidth}
 		\centering
 		\includegraphics[width=.9\linewidth]{taskex1}
@@ -54,10 +61,149 @@ enterName = enterInformation "Enter your name" []
 	\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
-specialization instances for these functions and show an according interface.
-Generated interfaces can be modified with decoration operators.
+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; namely 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 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.
 
-\subsection{Combinators}
-\todo{Stukje over combinators, in ieder geval bind en paralel}
+\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} that is in the current
+library functions fixed to the void type (i.e. \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
+\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 a \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
+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}