methods.tex

   1 \section{\acrlong{TOP}}
   2 \gls{TOP} is a recent new programming paradigm implemented as
   3 \gls{iTasks}~\cite{achten_introduction_2015} in
   4 the pure lazy functional language \gls{Clean}
   5
   6 \todo{Main terms}
   7 The lazy functional programming language based on graph rewriting
   8 \gls{Clean}~\cite{brus_cleanlanguage_1987}
   9
  10 \section{\acrlong{EDSL}s}
  11 \glspl{mTask} are expressed in a class based shallowly embedded \gls{EDSL}.
  12 There are two main types of \glspl{EDSL}.
  13 \todo{Small shallow embedded dsl intro}
  14 \todo{Small deep embedded dsl}
  15 \todo{Show that class based has the best of both worlds}
  16
  17 \section{Architecture}
  18 \section{Devices}
  19
  20 The client code for the devices is compiled from one codebase. For a device to
  21 be eligible for \glspl{mTask} it must be able to compile the shared codebase
  22 and implement (part of) the device specific interface. The shared codebase only
  23 uses standard \gls{C} and no special libraries or tricks are used. Therefore
  24 the code is compilable for almost any device or system. Note that it is not
  25 needed to implement a full interface\todo{handshake}. The full interface,
  26 listed in Appendix~\label{app:device-interface}\todo{update interface listing},
  27 also includes functions for accessing the peripherals that not every device
  28 might have. Devices can choose what to implement by setting the correct macros
  29 in the top of the file.
  30 \todo{Supported devices}
  31
  32 \subsection{Specification}
  33 Devices are stored in a record type and all devices in the system are stored in
  34 a \gls{SDS} containing all devices. From the macro settings in the interface
  35 file a profile is created for the device that describes the specification. When
  36 a connection between the server and a client is established the server will
  37 send a request for specification. The client will serialize his specs and send
  38 it to the server so that the server knows what the client is capable of. The
  39 exact specification is listed in Listing~\ref{lst:devicespec}
  40
  41 \begin{lstlisting}[language=Clean,label={lst:devicespec},
  42         caption={Device specification for \glspl{mTask}}]
  43 :: MTaskDeviceSpec =
  44         {haveLed :: Bool
  45         ,haveAio :: Bool
  46         ,haveDio :: Bool
  47         ,taskSpace :: Int // Bytes
  48         ,sdsSpace  :: Int // Bytes
  49         }
  50 \end{lstlisting}
  51 \todo{Explain specification, combine task and share space}
  52
  53 \subsection{Communication}
  54
  55 \section{mTasks}
  56 \subsection{\gls{EDSL}}
  57 The \gls{mTask}-\gls{EDSL} contains several classes that need to be implemented
  58 by a type for it to be an \gls{mTask}. For numeric and boolean arithmetic the
  59 classes \texttt{arith} and \texttt{boolExpr} are available and listed in a
  60 shortened version in Listing~\ref{lst:arithbool}. All classes are to be
  61 implemented by types of kind \texttt{*->*->*} a type \texttt{v t p},
  62 respectively a view with a type and the role.
  63
  64 \texttt{lit} lifts a constant to the \gls{mTask} domain. For a type to be a
  65 valid \gls{mTask} type it needs to implement the \texttt{mTaskType} class. The
  66 binary operators work as expected.
  67
  68 \begin{lstlisting}[language=Clean,label={lst:arithbool},
  69         caption={Basic classes for expressions}]
  70 class mTaskType a | toByteCode, fromByteCode, iTask, TC a
  71
  72 class arith v where
  73   lit :: t -> v t Expr | mTaskType t
  74   (+.) infixl 6 :: (v t p) (v t q) -> v t Expr | type, +, zero t & isExpr p & isExpr q
  75   ...
  76 class boolExpr v where
  77   (&.) infixr 3 :: (v Bool p) (v Bool q) -> v Bool Expr | isExpr p & isExpr q
  78   Not           :: (v Bool p) -> v Bool Expr | isExpr p
  79   ...
  80   (==.) infix 4 :: (v a p) (v a q) -> v Bool Expr | ==, toCode a & isExpr p & isExpr q
  81 \end{lstlisting}
  82
  83
  84 \subsection{Tasks}
  85
  86 \subsection{Shares}
  87 Shares can live on multiple clients at the same time. For every share created
  88 for an \gls{mTask} a real \gls{SDS} is created that mirrors the value on the
  89 client. All shares currently in use are stored in a system-wide \gls{SDS} in
  90 such a way that the actual share can be retrieved at any moment. All shares
  91 have a unique numeric identifier and an initial value.
  92
  93 \begin{lstlisting}[language=Clean,label={lst:sharespec}, caption={\acrlong{SDS}}]
  94 :: BCValue = E.e: BCValue e & mTaskType e
  95 :: MTaskShareType = MTaskWithShare String | MTaskLens String
  96 :: MTaskShare =
  97         {withTask :: [String]
  98         ,withDevice :: [String]
  99         ,identifier :: Int
 100         ,realShare :: MTaskShareType
 101         ,value :: BCValue
 102         }
 103
 104 sdsStore :: Shared [MTaskShare]
 105 \end{lstlisting}
 106 \todo{Do something with the sharetype}
 107
 108 \subsection{Communication}
 109 %\todo{Handshake, device specification sending, spec.c}
 110 %\todo{mTaskDevice class interface}
 111
 112 \section{mTasks}
 113 \subsection{\gls{EDSL}}
 114 \todo{Show the classes}
 115
 116 \subsection{Shares}
 117 \todo{Show the types and why}
 118
 119 Shares are used to store the values
 120
 121 Shares all have