X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=methods.top.tex;h=811e12a1c85df94705541c400588d98ef73e5880;hb=b8e0188d0d4b4f321259e036807b439c85753828;hp=ec330c92f29cf132aa1232aebd6d6c2045ba6056;hpb=f2e00e1e8180d06fc78f66ca99ea07f583f9056f;p=msc-thesis1617.git diff --git a/methods.top.tex b/methods.top.tex index ec330c9..811e12a 100644 --- a/methods.top.tex +++ b/methods.top.tex @@ -1,13 +1,13 @@ \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{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 +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 @@ -63,47 +63,23 @@ enterName = enterInformation "Enter your name" [] 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 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; 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) [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) @@ -118,27 +94,57 @@ Listing~\ref{lst:combinators}. (-&&-) 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 -memory, other shares and hardware. +\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 -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. +\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. \begin{lstlisting}[% label={lst:shares},caption={\Gls{SDS} functions}] @@ -161,27 +167,43 @@ sharedStore :: String a -> Shared a | JSONEncode{|*|}, JSONDecode{|*|} 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. +\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 \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. +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 -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. +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}