add text on mTask extensions, introduce bytecode view

diff --git a/results.arch.tex b/results.arch.tex
index 30fbc7a..87a25cb 100644 (file)
--- a/results.arch.tex
+++ b/results.arch.tex
@@ -150,10 +150,10 @@ function and the record is updated accordingly.
 
 \begin{figure}[H]
        \begin{sequencediagram}
-               \newthread{c}{Server}
-               \newinst[4]{s}{Client}
-               \mess{c}{MTSpec}{s}
-               \mess{s}{MTDevSpec d}{c}
+               \newthread{s}{Server}
+               \newinst[4]{c}{Client}
+               \begin{call}{s}{MTSpec}{c}{MTDevSpec}
+               \end{call}
        \end{sequencediagram}
        \caption{Connect a device}\label{fig:handshake}
 \end{figure}

diff --git a/results.mtask.tex b/results.mtask.tex
index 8b0fb20..8c22015 100644 (file)
--- a/results.mtask.tex
+++ b/results.mtask.tex
@@ -5,14 +5,34 @@ 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 view}
+\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 \gls{RWST}
-is used. The \gls{RWST} is a state transformer stacked on a \emph{Reader} monad
-and a \emph{Writer} monad. In this case the transformer part is not used.
-However, this can be done to add for example better runtime error handling.
+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.
 
-\begin{lstlisting}[language=Clean]
+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 = {
@@ -37,12 +57,14 @@ instance arith ByteCode
 instance serial ByteCode
 \end{lstlisting}
 
-\section{Bytecode compilation view for \gls{mTask}}
-Compilation to bytecode
+\section{Implementation}
+\subsection{Helper functions}
+
+\subsection{Arithmetics}
+
+\subsection{Control Flow}
 
-\subsection{Backend}
-\todo{Aanpassingen
-aan de mTask DSL}
+\subsection{Shared Data Sources}
 
 \section{Semantics}