\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 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}, also includes functions for
accessing the peripherals that not every device might have.

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


\section{mTasks}
\subsection{\gls{EDSL}}

\subsection{Shares}
%\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}
