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
+filled in and therefore the \CI{TaskValue} remains \CI{NoValue}. 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.
\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
+types of combinators; 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}
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
+inspect the value of an \gls{SDS} and act upon a change. \Glspl{Task} waiting on
+an \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.
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}
+Parametric lenses add a type variable to the \gls{SDS}. This type variable is
+fixed to the void type (i.e. \CI{()}) in the given functions. When an \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
+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
-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}.
+Functionality for setting parameters is available 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}]