Some functionality of the original \gls{mTask}-\gls{EDSL} will not be used in
this extension \gls{EDSL}. Conversely, some functionality needed was not
available in the existing \gls{EDSL}. Due to the nature of class based shallow
embedding this obstacle is very easy to solve. A type housing the \gls{EDSL}
does not have to implement all the available classes. Moreover, classes can be
added at will without interfering with the existing views.

\section{Bytecode compilation}
The \glspl{mTask} are sent to the device in bytecode and are saved in the
memory of the device. To compile the \gls{EDSL} code to bytecode, a view is
added to the \gls{mTask}-system called \CI{ByteCode}. As shown in
Listing~\ref{lst:bcview}, the \CI{ByteCode} view is a boxed \gls{RWST} that
writes bytecode instructions (\CI{BC}) while carrying around a \CI{BCState}.
The state is kept between devices and contains fresh variable names and a
register of shares used.

Types implementing the \gls{mTask} classes must have two free type variables.
Therefore the \gls{RWST} is wrapped with a constructor and two phantom type
variables are added. This means that the programmer has to unbox the
\CI{ByteCode} object to be able to use return values for the monad. Tailor made
access functions are used to achieve this with ease. The fresh variable stream
in a compiler using an \gls{RWST} is often put in to the \emph{Reader} part of
the monad. However, not all code is compiled immediately and later on the fresh
variable stream can not contain variables that were used before. Therefore this
information is put in the state which is kept between compilations.

Not all types are suitable for usage in bytecode compiled programs. Every value
used in the bytecode view must fit in the \CI{BCValue} type which restricts
the content. Most notably, the type must be bytecode encodable.  A \CI{BCValue}
must be encodable and decodable without losing type or value information. At
the moment a simple encoding scheme is used that uses a single byte prefixes to
detect which type the value is. The devices know of these prefixes and act
accordingly.

\begin{lstlisting}[language=Clean,label={lst:bcview},caption={Bytecode view}]
:: ByteCode a p = BC (RWS () [BC] BCState ())
:: BCValue = E.e: BCValue e & mTaskType, TC e
:: BCShare = {
		sdsi :: Int,
		sdsval :: BCValue
	}
:: BCState = {
		freshl :: [Int],
		freshs :: [Int],
		sdss :: [BCShare]
	}

class toByteCode a :: a -> String
class fromByteCode a :: String -> a
class mTaskType a | toByteCode, fromByteCode, iTask, TC a

instance toByteCode Int, ... , UserLED, BCValue
instance fromByteCode Int, ... , UserLED, BCValue

instance arith ByteCode
...
instance serial ByteCode
\end{lstlisting}

\section{Implementation}
\subsection{Helper functions}

\subsection{Arithmetics}

\subsection{Control Flow}

\subsection{Shared Data Sources}

\section{Semantics}

\todo{Uitleggen wat het systeem precies doet}

