+\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}\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}
+
+\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}.
+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}
\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
+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\todo{handshake}. 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.
+\todo{Supported devices}
+
\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
+ ,taskSpace :: Int // Bytes
+ ,sdsSpace :: Int // Bytes
+ }
+\end{lstlisting}
+\todo{Explain specification, combine task and share space}
\subsection{Communication}
\section{mTasks}
-\subsection{\gls{DSL}}
+\subsection{\gls{EDSL}}
+The \gls{mTask}-\gls{EDSL} contains several classes that need to be implemented
+by a type for it to be an \gls{mTask}. For numeric and boolean arithmetic the
+classes \texttt{arith} and \texttt{boolExpr} are available and listed in a
+shortened version in Listing~\ref{lst:arithbool}. All classes are to be
+implemented by types of kind \texttt{*->*->*} a type \texttt{v t p},
+respectively a view with a type and the role.
+
+\texttt{lit} lifts a constant to the \gls{mTask} domain. For a type to be a
+valid \gls{mTask} type it needs to implement the \texttt{mTaskType} class. The
+binary operators work as expected.
+
+\begin{lstlisting}[language=Clean,label={lst:arithbool},
+ caption={Basic classes for expressions}]
+class mTaskType a | toByteCode, fromByteCode, iTask, TC a
+
+class arith v where
+ lit :: t -> v t Expr | mTaskType t
+ (+.) infixl 6 :: (v t p) (v t q) -> v t Expr | type, +, zero t & isExpr p & isExpr q
+ ...
+class boolExpr v where
+ (&.) infixr 3 :: (v Bool p) (v Bool q) -> v Bool Expr | isExpr p & isExpr q
+ Not :: (v Bool p) -> v Bool Expr | isExpr p
+ ...
+ (==.) infix 4 :: (v a p) (v a q) -> v Bool Expr | ==, toCode a & isExpr p & isExpr q
+\end{lstlisting}
+
+
+\subsection{Tasks}
+
+\subsection{Shares}
+Shares can live on multiple clients at the same time. For every share created
+for an \gls{mTask} a real \gls{SDS} is created that mirrors the value on the
+client. All shares currently in use are stored in a system-wide \gls{SDS} in
+such a way that the actual share can be retrieved at any moment. All shares
+have a unique numeric identifier and an initial value.
+
+\begin{lstlisting}[language=Clean,label={lst:sharespec}, caption={\acrlong{SDS}}]
+:: BCValue = E.e: BCValue e & mTaskType e
+:: MTaskShareType = MTaskWithShare String | MTaskLens String
+:: MTaskShare =
+ {withTask :: [String]
+ ,withDevice :: [String]
+ ,identifier :: Int
+ ,realShare :: MTaskShareType
+ ,value :: BCValue
+ }
+
+sdsStore :: Shared [MTaskShare]
+\end{lstlisting}
+\todo{Do something with the sharetype}
+
+\subsection{Communication}
+%\todo{Handshake, device specification sending, spec.c}
+%\todo{mTaskDevice class interface}
+
+\section{mTasks}
+\subsection{\gls{EDSL}}
+\todo{Show the classes}
\subsection{Shares}
+\todo{Show the types and why}
+
+Shares are used to store the values
+
+Shares all have
repositories / msc-thesis1617.git / blobdiff