methods.tex

   1 \section{\acrlong{TOP}}
   2 \subsection{\gls{iTasks}}
   3 \gls{TOP} is a recent new programming paradigm implemented as
   4 \gls{iTasks}\cite{achten_introduction_2015} in the pure lazy functional
   5 language \gls{Clean}\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a
   6 \gls{EDSL} to model workflow tasks in the broadest sense. A \CI{Task} is just
   7 a function that, given some state, returns the observable value of the
   8 \CI{TaskValue}. A simple example is shown in Listing~\ref{lst:taskex}
   9 accompanied with Figure~\ref{fig:taskex1},~\ref{fig:taskex2} and~%
  10 \ref{fig:taskex3}.
  11
  12 \begin{lstlisting}[language=Clean,label={lst:taskex},%
  13         caption={An example \gls{Task} for entering a name}]
  14 :: Name         = { firstname :: String
  15                   , lastname  :: String
  16                                   }
  17
  18 derive class iTask Name
  19
  20 enterInformation :: String [EnterOption m] -> (Task m) | iTask m
  21
  22 enterName :: Task Name
  23 enterName = enterInformation "Enter your name" []
  24 \end{lstlisting}
  25
  26 \begin{figure}[H]
  27         \begin{subfigure}{.25\textwidth}
  28                 \centering
  29                 \includegraphics[width=.9\linewidth]{taskex1}
  30                 \caption{Initial interface}\label{fig:taskex1}
  31         \end{subfigure}
  32         \begin{subfigure}{.25\textwidth}
  33                 \centering
  34                 \includegraphics[width=.9\linewidth]{taskex2}
  35                 \caption{Incomplete entrance}\label{fig:taskex2}
  36         \end{subfigure}
  37         \begin{subfigure}{.25\textwidth}
  38                 \centering
  39                 \includegraphics[width=.9\linewidth]{taskex3}
  40                 \caption{Complete entry}\label{fig:taskex3}
  41         \end{subfigure}
  42         \caption{Example of a generated user interface}
  43 \end{figure}
  44
  45 \subsection{Combinators}
  46
  47 \section{\acrlong{EDSL}s}
  48 \todo{while iTasks is also a DSL\ldots}
  49 \glspl{mTask} are expressed in a class based shallowly embedded \gls{EDSL}.
  50 There are two main types of \glspl{EDSL}.
  51 \todo{Small shallow embedded dsl intro}
  52 \todo{Small deep embedded dsl}
  53 \todo{Show that class based has the best of both worlds}
  54
  55 \section{Architecture}
  56 \subsection{Devices}
  57 The client code for the devices is compiled from one codebase. For a device to
  58 be eligible for \glspl{mTask} it must be able to compile the shared codebase
  59 and implement (part of) the device specific interface. The shared codebase only
  60 uses standard \gls{C} and no special libraries or tricks are used. Therefore
  61 the code is compilable for almost any device or system. Note that it is not
  62 needed to implement a full interface. The full interface, listed in
  63 Appendix~\label{app:device-interface}\todo{update interface listing}, also
  64 includes functions for accessing the peripherals that not every device might
  65 have. Devices can choose what to implement by setting the correct macros in the
  66 top of the file. When a server connects to a client the specifications are
  67 communicated.
  68
  69 The current list of supported and tested devices is as follows:
  70 \begin{itemize}
  71         \item $^*$\texttt{NIX} systems such as Linux
  72         \item STM32 like development boards supported by \texttt{ChibiOS}.
  73         \item \emph{Arduino} compatible microcontrollers
  74 \end{itemize}
  75
  76 \subsection{Specification}
  77 Devices are stored in a record type and all devices in the system are stored in
  78 a \gls{SDS} containing all devices. From the macro settings in the interface
  79 file a profile is created for the device that describes the specification. When
  80 a connection between the server and a client is established the server will
  81 send a request for specification. The client will serialize his specs and send
  82 it to the server so that the server knows what the client is capable of. The
  83 exact specification is listed in Listing~\ref{lst:devicespec}
  84
  85 \begin{lstlisting}[language=Clean,label={lst:devicespec},
  86         caption={Device specification for \glspl{mTask}}]
  87 :: MTaskDeviceSpec =
  88         {haveLed     :: Bool
  89         ,haveAio     :: Bool
  90         ,haveDio     :: Bool
  91         ,bytesMemory :: Int
  92         }
  93 \end{lstlisting}
  94 \todo{Explain specification, combine task and share space}
  95
  96 \subsection{Communication}
  97
  98 \section{mTasks}
  99 \subsection{\gls{EDSL}}
 100 The \gls{mTask}-\gls{EDSL} contains several classes that need to be implemented
 101 by a type for it to be an \gls{mTask}. For numeric and boolean arithmetic the
 102 classes \texttt{arith} and \texttt{boolExpr} are available and listed in a
 103 shortened version in Listing~\ref{lst:arithbool}. All classes are to be
 104 implemented by types of kind \texttt{*->*->*} a type \texttt{v t p},
 105 respectively a view with a type and the role.
 106
 107 \texttt{lit} lifts a constant to the \gls{mTask} domain. For a type to be a
 108 valid \gls{mTask} type it needs to implement the \texttt{mTaskType} class. The
 109 binary operators work as expected.
 110
 111 \begin{lstlisting}[language=Clean,label={lst:arithbool},
 112         caption={Basic classes for expressions}]
 113 class mTaskType a | toByteCode, fromByteCode, iTask, TC a
 114
 115 class arith v where
 116   lit :: t -> v t Expr | mTaskType t
 117   (+.) infixl 6 :: (v t p) (v t q) -> v t Expr | type, +, zero t & isExpr p & isExpr q
 118   ...
 119 class boolExpr v where
 120   (&.) infixr 3 :: (v Bool p) (v Bool q) -> v Bool Expr | isExpr p & isExpr q
 121   Not           :: (v Bool p) -> v Bool Expr | isExpr p
 122   ...
 123   (==.) infix 4 :: (v a p) (v a q) -> v Bool Expr | ==, toCode a & isExpr p & isExpr q
 124 \end{lstlisting}
 125
 126
 127 \subsection{Tasks}
 128
 129 \subsection{Shares}
 130 Shares can live on multiple clients at the same time. For every share created
 131 for an \gls{mTask} a real \gls{SDS} is created that mirrors the value on the
 132 client. All shares currently in use are stored in a system-wide \gls{SDS} in
 133 such a way that the actual share can be retrieved at any moment. All shares
 134 have a unique numeric identifier and an initial value.
 135
 136 \begin{lstlisting}[language=Clean,label={lst:sharespec}, caption={\acrlong{SDS}}]
 137 :: BCValue = E.e: BCValue e & mTaskType e
 138 :: MTaskShareType = MTaskWithShare String | MTaskLens String
 139 :: MTaskShare =
 140         {withTask :: [String]
 141         ,withDevice :: [String]
 142         ,identifier :: Int
 143         ,realShare :: MTaskShareType
 144         ,value :: BCValue
 145         }
 146
 147 sdsStore :: Shared [MTaskShare]
 148 \end{lstlisting}
 149 \todo{Do something with the sharetype}
 150
 151 \subsection{Communication}
 152 %\todo{Handshake, device specification sending, spec.c}
 153 %\todo{mTaskDevice class interface}
 154
 155 \section{mTasks}
 156 \subsection{\gls{EDSL}}
 157 \todo{Show the classes}
 158
 159 \subsection{Shares}
 160 \todo{Show the types and why}
 161
 162 Shares are used to store the values
 163
 164 Shares all have