results.mtask.tex

   1 Some functionality of the original \gls{mTask}-\gls{EDSL} will not be used in
   2 this extension \gls{EDSL}. Conversely, some functionality needed was not
   3 available in the existing \gls{EDSL}. Due to the nature of class based shallow
   4 embedding this obstacle is very easy to solve. A type housing the \gls{EDSL}
   5 does not have to implement all the available classes. Moreover, classes can be
   6 added at will without interfering with the existing views.
   7
   8 \section{Bytecode compilation}
   9 The \glspl{mTask} are sent to the device in bytecode and are saved in the
  10 memory of the device. To compile the \gls{EDSL} code to bytecode, a view is
  11 added to the \gls{mTask}-system called \CI{ByteCode}. As shown in
  12 Listing~\ref{lst:bcview}, the \CI{ByteCode} view is a boxed \gls{RWST} that
  13 writes bytecode instructions (\CI{BC}) while carrying around a \CI{BCState}.
  14 The state is kept between devices and contains fresh variable names and a
  15 register of shares used.
  16
  17 Types implementing the \gls{mTask} classes must have two free type variables.
  18 Therefore the \gls{RWST} is wrapped with a constructor and two phantom type
  19 variables are added. This means that the programmer has to unbox the
  20 \CI{ByteCode} object to be able to use return values for the monad. Tailor made
  21 access functions are used to achieve this with ease. The fresh variable stream
  22 in a compiler using an \gls{RWST} is often put in to the \emph{Reader} part of
  23 the monad. However, not all code is compiled immediately and later on the fresh
  24 variable stream can not contain variables that were used before. Therefore this
  25 information is put in the state which is kept between compilations.
  26
  27 Not all types are suitable for usage in bytecode compiled programs. Every value
  28 used in the bytecode view must fit in the \CI{BCValue} type which restricts
  29 the content. Most notably, the type must be bytecode encodable.  A \CI{BCValue}
  30 must be encodable and decodable without losing type or value information. At
  31 the moment a simple encoding scheme is used that uses a single byte prefixes to
  32 detect which type the value is. The devices know of these prefixes and act
  33 accordingly.
  34
  35 \begin{lstlisting}[language=Clean,label={lst:bcview},caption={Bytecode view}]
  36 :: ByteCode a p = BC (RWS () [BC] BCState ())
  37 :: BCValue = E.e: BCValue e & mTaskType, TC e
  38 :: BCShare = {
  39                 sdsi :: Int,
  40                 sdsval :: BCValue
  41         }
  42 :: BCState = {
  43                 freshl :: [Int],
  44                 freshs :: [Int],
  45                 sdss :: [BCShare]
  46         }
  47
  48 class toByteCode a :: a -> String
  49 class fromByteCode a :: String -> a
  50 class mTaskType a | toByteCode, fromByteCode, iTask, TC a
  51
  52 instance toByteCode Int, ... , UserLED, BCValue
  53 instance fromByteCode Int, ... , UserLED, BCValue
  54
  55 instance arith ByteCode
  56 ...
  57 instance serial ByteCode
  58 \end{lstlisting}
  59
  60 \section{Implementation}
  61 \subsection{Helper functions}
  62
  63 \subsection{Arithmetics}
  64
  65 \subsection{Control Flow}
  66
  67 \subsection{Shared Data Sources}
  68
  69 \section{Semantics}
  70
  71 \todo{Uitleggen wat het systeem precies doet}
  72