\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}

\todo{Main terms}
The lazy functional programming language based on graph rewriting
\gls{Clean}~\cite{brus_cleanlanguage_1987}

\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{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. 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}, also includes functions for accessing
the peripherals that not every device might have. The interface headers also
show which functionality is implemented and which functionality is not
available. This information is exchanged during the setup of the communication.

\subsection{Specification}
Devices are stored in a record type and all devices in the system are stored in
a \gls{SDS} containing all devices.

\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
%\subsection{Serial port communication in Clean and iTasks}
%In the first exploration stage I added duplex serial port communication to
%iTasks in the same way as TCP is added. To make it work several changes had to
%be done to the iTasks core to allow backgroundtasks to be added at runtime. The
%function shown in Listing~\ref{lst:serialtask} results into a task that
%sends the data added to the output queue through the serial port and adds data
%received to the input queue for the user to process.
%
%\begin{lstlisting}[caption={Serial port communication in iTasks},
%	language=Clean,label={lst:serialtask}]
%syncSerialChannel :: String TTYSettings (Shared ([String],[String],Bool)) -> Task ()
%
%:: ByteSize = BytesizeFive | BytesizeSix | BytesizeSeven | BytesizeEight
%:: Parity = ParityNone | ...ParityOdd | ParityEven | ParitySpace | ParityMark
%:: BaudRate = ... | B9600 | B19200 | ...
%:: TTYSettings = {
%	baudrate :: BaudRate,
%	bytesize :: ByteSize,
%	parity :: Parity,
%	stop2bits :: Bool,
%	xonxoff :: Bool}
%\end{lstlisting}
%
%\subsection{mTasks}
%The core of the project revolves around the embedded domain specific language
%(EDSL) called mTask designed by Pieter Koopman. mTasks is used to use the task
%oriented programming on microcontrollers in a type-safe environment. Originally
%mTasks are compiled to c code that could be compiled for arduino compatible
%devices.  Such generated code will be flashed to the program memory once. In
%short, the original mTask system is comparable to an entire iTasks sytem
%including the engine.
%
%For this project the imperative language constructs of the mTask DSL are used.
%Listing~\ref{lst:mtask} shows some of these class base DSL components for
%things like arithmetics, sequencing, conditionals, shared data sources and
%interaction with the user LEDs. Together with some helper functions code
%programmed in this DSL can be compiled to bytecode and sent to a device.
%
%\begin{lstlisting}[language=Clean,label={lst:mtask},
%	caption={Parts of the mTask DSL}]
%:: Upd   = Upd
%:: Expr  = Expr
%:: Stmt  = Stmt
%:: UserLED = LED1 | LED2 | LED3
%
%:: Main a = {main :: a}
%
%class arith v where
%  lit :: t -> v t Expr | ...
%  (+.) infixl 6 :: (v t p) (v t q) -> v t Expr | ...
%class IF v where
%  IF :: (v Bool p) (v t q) (v s r) -> v () Stmt | isExpr p
%class sds v where
%  sds :: ((v t Upd)->In t (Main (v c s))) -> (Main (v c s)) | ...
%  pub :: (v t Upd) -> v t Expr | ...
%class seq v where
%  (:.) infixr 0 :: (v t p) (v u q) -> v u Stmt | ...
%class assign v where
%  (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ...
%class noOp v where noOp :: v t p
%class userLed v where
%	ledOn :: UserLED -> (v () Stmt)
%	ledOff :: UserLED -> (v () Stmt)
%\end{lstlisting}
%
%\subsection{iTasks}
%In iTasks several tasks have been devised to handle the communication. Moreover
%the tasks will synchronize the shared data sources in the mTask domain with
%real SDSs in the iTasks domain allowing for communication between mTasks and
%iTasks tasks. To not clutter the communication channels the SDSs are not
%synchronized on every change on the device. When a share changes on the server
%his new value will be pushed to the device immediately. When a share is updated
%on the client it must be explicitly published using. This approach has been
%taken because some shares might be only used internally and therefore would
%clutter the communication channels that could be low-bandwidth.
%
%
%\subsection{Devices}
%For the devices an engine has been built that can receive mTasks and SDSs and
%execute them accordingly. To add a new device to the list the programmer just
%has to implement a relatively small interface. All the other functionality is
%using standard C or the interface. This interface is listed in~%
%\ref{lst:interface} and includes reading and writing data, controlling the
%peripherals and some auxiliary functions.
%
%\begin{lstlisting}[language=c,caption={Device interface},label={lst:interface}]
%uint8_t read_byte(void);
%void write_byte(uint8_t b);
%
%void write_dpin(uint8_t i, bool b);
%bool read_dpin(uint8_t i);
%
%void write_apin(uint8_t i, uint8_t a);
%uint8_t read_apin(uint8_t i);
%
%long millis(void);
%bool input_available(void);
%void delay(long ms);
%
%void setup(void);
%void debug(char *fmt, ...);
%void pdie(char *s);
%void die(char *fmt, ...);
%\end{lstlisting}
%
%mTasks run either at a fixed interval or are one-shot which is added to the
%message. The entire protocol specification can be found in the code that is
%available. When an mTask is one-shot it will only be executed once and then
%removed. This can be useful for user related tasks such as shutting down blinds
%or turning on lights for an indefinite time. mTasks that run at a fixed
%interval time can be used to monitor sensors or to periodically communicate
%with peripherals like LCD screens.
%
%There are many things to be improved upon in future research. Most likely these
%points will be touched upon in my Master's thesis research.
%\begin{itemize}
%	\item Support task combinators and functions.
%
%		The mTask language already supports the step combinator and it might be
%		fruitful to add for more expressively. Moreover functions would also
%		add a lot. They can be used to share code between tasks to reduce the
%		bytecode size.
%	\item Seamless integration with iTasks.
%
%		At the moment everything works but is hacked together. I would like to
%		extend this with a more robust system that allows adding devices on the
%		fly and adds functionality to monitor the mTask devices.
%	\item Dynamic mTask/SDS allocation.
%
%		Currently all client data for mTask and SDS storage is statically
%		allocated. This means that when only a few tasks are used the memory
%		needed is too high. This can be improved upon by only allocating
%		resources for tasks when they are requested and this would allow the
%		system to run on low memory devices like arduino's.
%	\item Extend on SDSs.
%
%		In the current system the shared data sources used in mTask programs
%		live in a different domain and are synchronized with an iTask
%		counterpart. Programming mTasks could be made more intuitive if you
%		could use standard SDSs from iTasks. Moreover, at the moment only
%		integer and boolean shares are allowed. This really should be extended
%		to at least strings.
%	\item Slicing tasks.
%
%		Every mTask runs in its entirety and to not run into race and
%		scheduling problems loops are not allowed in the mTasks. An improvement
%		to this could be multithreading the tasks by giving them slices of
%		computation and pausing them every slice. In this way loops could be
%		allowed without blocking the entire system. It does require more memory
%		however.
%	\item Run tasks when an interrupt fires.
%
%		Tasks can be scheduled either one-shot or at an interval. It might be
%		useful to tie mTasks to hardware interrupts to increase responsiveness
%		and possibly battery life. These interrupts do not need to be hardware
%		based. A usecase might be to run a task when some other task is
%		yielding a value (see task combinators) or to run a task when a shared
%		data source is received from the server.
%\end{itemize}
