\section{Discussion}
\todo{class based shallow doesn't have multiple backend support}
\todo{slow client software because of interpretation}
\todo{What happens if a device dies? Task resending, add to handshake}

\section{Future Research}
The system is still crude and a proof of concept. Improvements and extension
for the system are amply available in several fields of study.

\subsection{Simulation}
An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
works in the same way as the existing \gls{C}-backed simulation. It simulates
the bytecode interpretation. Moreover would be possible to let the simulator
function as a real device, thus handling all communication through the
existing \gls{SDS}-based systems and behave like a real device. At the moment
the \emph{POSIX}-client is the reference client and contains debugging code.
Adding a simulation view to the system allows for easy interactive debugging.
However, it might not be easy to devise a simulation tool that accurately
simulates the \gls{mTask} system accurately on some levels. The semantics can
be simulated but timing and peripheral input/output are more
difficult to simulate properly.

\subsection{Optimization}
True multitasking could be added to the client software. This allows
\gls{mTask}-\glspl{Task} to run truly parallel. All \glspl{mTask} get slices
of execution time and will each have their own interpreter state instead of one
system-wide one that is reset after am \gls{mTask} finishes. This does require
separate stacks for each \gls{Task} and therefore increases the system
requirements of the client software. However, it could be implemented as a
compile-time option and exchanged during the handshake so that the server knows
the multithreading capabilities of the client.

Hardly any work has been done in the interpreter. The current interpreter is a
no nonsense stack machine. A lot of improvements can be done in this part. For
example, precomputed \emph{gotos} can improve jumping to the correct part of
the code corresponding to the correct instruction.

\subsection{Resources}
Resource analysis during compilation can be useful to determine if an
\gls{mTask}-\gls{Task} is suitable for a specific device. If the device does
not contain the correct peripherals such as an \gls{LCD} then the
\gls{mTask}-\gls{Task} should be rejected and feedback to the user must be
given. 

This idea could be extended to the analysis of stack size and possibly
communication bandwidth. With this functionality ever more reliable fail-over
systems can be designed. When the system knows precise bounds it can
allocate more \glspl{Task} on a device whilst staying within safe memory
bounds. The resource allocation can be done at runtime within the backend
itself or a general backend can be devices that can calculate the resources
needed for a given \gls{mTask}. A specific \gls{mTask} cannot have multiple
views at the same time due to the restrictions of class based shallow
embedding. It might even be possible to encode the resource allocation in the
type system itself using forms of dependant types.

\subsection{Functionality}
More \gls{Task}-combinators already existing in the \gls{iTasks}-system could
be added to the \gls{mTask}-system to allow for more fine-grained control flow
between \gls{mTask}-\glspl{Task}. In this way the new system follows the
\gls{TOP} paradigm even more and makes programming \glspl{mTask} for
\gls{TOP}-programmers more seamless. Some of the combinators require previously
mentioned extension such as the parallel combinator. Others might be achieved
using simple syntactic transformations.

Currently the \gls{C}-view allows \glspl{Task} to launch other \glspl{Task}. In
the current system this type of logic has to take place server side. Adding
this functionality to the bytecode-view allows greater flexibility, easier
programming and less communication resources. Adding these semantics requires
modifications to the client software and extensions to the communication
protocol since relations between \glspl{Task} also need to be encoded and
communicated.
\section{Conclusion}
This thesis introduces a new view for the existing \gls{mTask}-\gls{EDSL}.
The new view for the \gls{EDSL} compiles the language in to bytecode that can
be interpreted by an \gls{mTask}-client. Clients have been written for several
microcontrollers and consumer architectures that can be connected through
various means of communication such as serial, bluetooth, wifi and wired
network communication. The bytecode on the devices is interpreted using a
simple stack machine and provides the programmer interfaces to the peripherals.
The semantics of the \glspl{mTask} tries to resemble the \gls{iTasks} semantics
as close as possible.

The host language has a very efficient compiler and code generator. Therefore,
the \gls{mTask}-system is also relatively fast because the compilation of
\glspl{mTask} is nothing more than running some functions in the host language.

The dynamic nature allows the microcontroller to be programmed once and used
many times. The program memory of microcontrollers often guarantees around
$10.000$ write or upload cycles and therefore existing techniques such as
generating \gls{C} code are not usable for dynamic \gls{Task} environments.
The dynamic nature also allows the programmer to design fail-over mechanisms.
When a device is assigned a \gls{Task} but another device suddenly becomes
unusable, the \gls{iTasks} system can reassign a new \gls{mTask}-\gls{Task} to
the first device that possibly takes over some of the functionality of the
broken device without needing to recompile the code.
