X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=methods.tex;h=473efcf090a714e2eac5fa98addf9ee3be0ca80c;hb=dc057560c806a535088e1d9ebdbdd0737467ecc3;hp=952986e19c6c7cd21c98a913956959a1fc009b7d;hpb=fd518360fae7c8bf40f0334997e6a516ef1e971d;p=msc-thesis1617.git

diff --git a/methods.tex b/methods.tex
index 952986e..473efcf 100644
--- a/methods.tex
+++ b/methods.tex
@@ -1,11 +1,45 @@
 \section{\acrlong{TOP}}
 \gls{TOP} is a recent new programming paradigm implemented as
-\gls{iTasks}~\cite{achten_introduction_2015} in
-the pure lazy functional language \gls{Clean}
+\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 value of the
+\CI{TaskValue}. A simple example is shown in Listing~\ref{lst:taskex}
+accompanied with Figure~\ref{fig:taskex1},~\ref{fig:taskex2} and~%
+\ref{fig:taskex3}.
+
+\begin{lstlisting}[language=Clean,label={lst:taskex},%
+	caption={An example \gls{Task} for entering a name}]
+:: Name         = { firstname :: String
+                  , lastname  :: String
+				  }
+
+derive class iTask Name
+
+enterInformation :: String [EnterOption m] -> (Task m) | iTask m
+
+enterName :: Task Name
+enterName = enterInformation "Enter your name" []
+\end{lstlisting}
 
-\todo{Main terms}
-The lazy functional programming language based on graph rewriting
-\gls{Clean}~\cite{brus_cleanlanguage_1987}
+\begin{figure}[H]
+	\begin{subfigure}{.25\textwidth}
+		\centering
+		\includegraphics[width=.9\linewidth]{taskex1}
+		\caption{Initial interface}\label{fig:taskex1}
+	\end{subfigure}
+	\begin{subfigure}{.25\textwidth}
+		\centering
+		\includegraphics[width=.9\linewidth]{taskex2}
+		\caption{Incomplete entrance}\label{fig:taskex2}
+	\end{subfigure}
+	\begin{subfigure}{.25\textwidth}
+		\centering
+		\includegraphics[width=.9\linewidth]{taskex3}
+		\caption{Complete entry}\label{fig:taskex3}
+	\end{subfigure}
+	\caption{Example of a generated user interface}
+\end{figure}
 
 \section{\acrlong{EDSL}s}
 \glspl{mTask} are expressed in a class based shallowly embedded \gls{EDSL}.
@@ -14,7 +48,9 @@ There are two main types of \glspl{EDSL}.
 \todo{Small deep embedded dsl}
 \todo{Show that class based has the best of both worlds}
 
+\section{Architecture}
 \section{Devices}
+
 The client code for the devices is compiled from one codebase. For a device to
 be eligible for \glspl{mTask} it must be able to compile the shared codebase
 and implement (part of) the device specific interface. The shared codebase only
@@ -25,6 +61,7 @@ listed in Appendix~\label{app:device-interface}\todo{update interface listing},
 also includes functions for accessing the peripherals that not every device
 might have. Devices can choose what to implement by setting the correct macros
 in the top of the file.
+\todo{Supported devices}
 
 \subsection{Specification}
 Devices are stored in a record type and all devices in the system are stored in