+\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}
+
+\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}
+
+\subsection{Combinators}
+
+\section{\acrlong{EDSL}s}
+\todo{while iTasks is also a DSL\ldots}
+\glspl{mTask} are expressed in a class based shallowly embedded \gls{EDSL}.
+There are two main types of \glspl{EDSL}.
+\todo{Small shallow embedded dsl intro}
+\todo{Small deep embedded dsl}
+\todo{Show that class based has the best of both worlds}
+
+\section{Architecture}
+\subsection{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
+uses standard \gls{C} and no special libraries or tricks are used. Therefore
+the code is compilable for almost any device or system. Note that it is not
+needed to implement a full interface. The full interface, 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. When a server connects to a client the specifications are
+communicated.
+
+The current list of supported and tested devices is as follows:
+\begin{itemize}
+ \item $^*$\texttt{NIX} systems such as Linux
+ \item STM32 like development boards supported by \texttt{ChibiOS}.
+ \item \emph{Arduino} compatible microcontrollers
+\end{itemize}
+
+\subsection{Specification}
+Devices are stored in a record type and all devices in the system are stored in
+a \gls{SDS} containing all devices. From the macro settings in the interface
+file a profile is created for the device that describes the specification. When
+a connection between the server and a client is established the server will
+send a request for specification. The client will serialize his specs and send
+it to the server so that the server knows what the client is capable of. The
+exact specification is listed in Listing~\ref{lst:devicespec}
+
+\begin{lstlisting}[language=Clean,label={lst:devicespec},
+ caption={Device specification for \glspl{mTask}}]
+:: MTaskDeviceSpec =
+ {haveLed :: Bool
+ ,haveAio :: Bool
+ ,haveDio :: Bool
+ ,bytesMemory :: Int
+ }
+\end{lstlisting}
+\todo{Explain specification, combine task and share space}
+
+\subsection{Communication}