X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=methods.top.tex;h=aefa35dba70220a456a8c35d3290adc82716fb03;hb=6863f12d2bffba5c1f4c6c7756a5ee641816ce11;hp=ec330c92f29cf132aa1232aebd6d6c2045ba6056;hpb=7694dfaa240c6dd9af2f1ac8880f0fb1d7f38324;p=msc-thesis1617.git

diff --git a/methods.top.tex b/methods.top.tex
index ec330c9..aefa35d 100644
--- a/methods.top.tex
+++ b/methods.top.tex
@@ -1,7 +1,7 @@
 \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{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 \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
@@ -71,8 +71,8 @@ Generated interfaces can be modified with decoration operators.
 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
+starts a new \gls{Task} according to specified predicates on the
+\CI{TaskValue}.  Type signatures of the basic combinators are shown in
 Listing~\ref{lst:combinators}.
 
 \begin{itemize}
@@ -126,19 +126,20 @@ system time, a random integer or just some data stored in memory. The actual
 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.
+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 +162,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}