add text on mTask extensions, introduce bytecode view

[msc-thesis1617.git] / results.mtask.tex

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.
 
 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
 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 = {
 :: 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}
 
 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}
 
 
 \section{Semantics}