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 aaa2515..8c22015 100644 (file)
--- a/results.mtask.tex
+++ b/results.mtask.tex
@@ -1,16 +1,72 @@
-\section{mTask}
-\subsection{Semantics}
-\todo{Uitleggen wat het systeem precies doet}
+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
 
-\subsection{Extension on the \gls{mTask}-\gls{EDSL}}
-\todo{Aanpassingen aan de mTask DSL}
+instance toByteCode Int, ... , UserLED, BCValue
+instance fromByteCode Int, ... , UserLED, BCValue
 
-\section{iTasks}
-\subsection{Shares}
-\todo{Semantiek van shares, hoe ze in iTasks zijn, hoe typering}
+instance arith ByteCode
+...
+instance serial ByteCode
+\end{lstlisting}
 
-\subsection{Lifting}
-\todo{Lift mTask taken naar echte taken, hoe werkt dat?}
+\section{Implementation}
+\subsection{Helper functions}
+
+\subsection{Arithmetics}
+
+\subsection{Control Flow}
+
+\subsection{Shared Data Sources}
+
+\section{Semantics}
+
+\todo{Uitleggen wat het systeem precies doet}
 
-\section{Demo}
-\todo{Wat voorbeeld code}