methods.mtask.tex

   1 \section{mTask}
   2 The \gls{mTask}-\gls{EDSL} is the basis on which the system is built. The
   3 \gls{mTask}-\gls{EDSL} was created by Koopman et al.\ to support several views
   4 such as an \gls{iTasks} simulation and a \gls{C}-code generator. The \gls{EDSL}
   5 was designed to generate a ready to compile \gls{TOP}-like system for
   6 microcontrollers such as the Arduino\cite{koopman_type-safe_nodate}%
   7 \cite{plasmeijer_shallow_2016}.
   8
   9 The \gls{mTask}-\gls{EDSL} is a shallowly embedded class based \gls{EDSL} and
  10 therefore it is very suitable to have a new backend that partly implements the
  11 given classes. The following subsections show the details of the \gls{EDSL}
  12 that are used in this extension. The parts of the \gls{EDSL} that are not used
  13 will not be discussed and the details of those parts can be found in the cited
  14 literature.
  15
  16 A view for the \gls{mTask}-\gls{EDSL} is a type of kind \CI{*->*->*} that
  17 implements some of the classes given. The types do not have to be present as
  18 fields in the higher kinded view and can, and will most often, solely be
  19 phantom types. A view is of the form \CI{v t r}. The first variable will be the
  20 type of the view, the second type variable will be the type of the
  21 \gls{EDSL}-expression and the third type variable represents the role of the
  22 expression. Currently the role of the expressions form a hierarchy. The three
  23 roles and their hierarchy are shown in Listing~\ref{lst:exprhier}. This implies
  24 that everything is a statement, only a \CI{Upd} and a \CI{Expr} are
  25 expressions. The \CI{Upd} restriction describes updatable expressions such as
  26 \gls{GPIO} pins and \gls{SDS}.
  27
  28 \begin{lstlisting}[%
  29         language=Clean,label={lst:exprhier},caption={Expression role hierarchy}]
  30 :: Upd   = Upd
  31 :: Expr  = Expr
  32 :: Stmt  = Stmt
  33
  34 class isExpr a :: a -> Int
  35 instance isExpr Upd
  36 instance isExpr Expr
  37 \end{lstlisting}
  38
  39 \subsection{Semantics}
  40 \gls{mTask} do not behave like functions but more like
  41 \gls{iTasks}-\glspl{Task}. When an \gls{mTask} is created it returns immediatly
  42 and the \gls{Task} will be executed sometime in the future. \glspl{Task} can
  43 run at an interval and they can start other tasks.
  44 \todo{Meer uitwijden over de mTask semantiek}
  45
  46 \subsection{Expressions}
  47 Expressions in the \gls{mTask}-\gls{EDSL} are divided into two types, namely
  48 boolean expressions and arithmetic expressions. The class of arithmetic
  49 language constructs also contains the function \CI{lit} that lifts a
  50 host-language value in to the \gls{EDSL} domain. All standard arithmetic
  51 functions are included but are omitted for brevity. Moreover the class
  52 restrictions are only shown in the first functions and are later omitted. Both
  53 the boolean expression and arithmetic expression classes are shown in
  54 Listing~\ref{lst:arithbool}.
  55
  56 \begin{lstlisting}[language=Clean,label={lst:arithbool},
  57         caption={Basic classes for expressions}]
  58 class arith v where
  59   lit           :: t -> v t Expr
  60   (+.) infixl 6 :: (v t p) (v t q) -> v t Expr          | +, zero t    & isExpr p & isExpr q
  61   (-.) infixl 6 :: (v t p) (v t q) -> v t Expr          | -, zero t    & ...
  62   ...
  63 class boolExpr v where
  64   Not           :: (v Bool p) -> v Bool Expr            | ...
  65   (&.) infixr 3 :: (v Bool p) (v Bool q) -> v Bool Expr | ...
  66   ...
  67   (==.) infix 4 :: (v a p) (v a q) -> v Bool Expr       | ==, toCode a & ...
  68 \end{lstlisting}
  69
  70 \subsection{Control flow}
  71 Looping of \glspl{Task} happens because \glspl{Task} are launched at regular
  72 intervals or relaunch themselves. Therefore there is no need for loop control
  73 flow functionality such as \CI{While} or \CI{For} constructions. The main
  74 control flow is the sequence operator and the \CI{If} statement. Both are shown
  75 in Listing~\ref{lst:control}. The first class of \CI{If} statements describe
  76 the regular if statement. The expressions given can have any role. The
  77 functional dependency on \CI{s} determines the return type of the statement.
  78 The sequence operator is very straightforward and just ties the two expressions
  79 together in sequence.
  80
  81 \begin{lstlisting}[%
  82         language=Clean,label={lst:control},caption={Control flow operators}]
  83 class If v q r ~s where
  84   If :: (v Bool p) (v t q) (v t r) -> v t s | ...
  85
  86 class seq v where
  87   (:.) infixr 0 :: (v t p) (v u q) -> v u Stmt | ...
  88 \end{lstlisting}
  89
  90 \subsection{Input/Output and class extensions}
  91 All expressions that have an \CI{Upd} role can be assigned to. Examples of such
  92 expressions are \glspl{SDS} and \gls{GPIO}. Moreover, class extensions can be
  93 created for specific peripherals such as user LEDs. The classes facilitating
  94 this are shown in Listing~\ref{lst:sdsio}. In this way the assignment is the
  95 same for every assignable entity.
  96
  97 \begin{lstlisting}[%
  98         language=Clean,label={lst:sdsio},caption={Input/Output classes}]
  99 :: DigitalPin = D0 | D1 | D2 | D3 | D4 | D5 |D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13
 100 :: AnalogPin  = A0 | A1 | A2 | A3 | A4 | A5
 101 :: UserLED = LED1 | LED2 | LED3
 102
 103 class dIO v where dIO :: DigitalPin -> v Bool Upd
 104 class aIO v where aIO :: AnalogPin -> v Int Upd
 105 class analogRead v where
 106   analogRead :: AnalogPin -> v Int Expr
 107   analogWrite :: AnalogPin (v Int p) -> v Int Expr
 108 class digitalRead v where
 109   digitalRead :: DigitalPin -> v Bin Expr
 110   digitalWrite :: DigitalPin (v Bool p) -> v Int Expr
 111
 112 :: UserLED = LED1 | LED2 | LED3
 113 class userLed v where
 114   ledOn  :: (v UserLED q) -> (v () Stmt)
 115   ledOff :: (v UserLED q) -> (v () Stmt)
 116
 117 class assign v where
 118   (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ...
 119 \end{lstlisting}
 120
 121 A way of storing data in \glspl{mTask} is using \glspl{SDS}. \glspl{SDS} serve
 122 as variables in the \gls{mTask} and will keep their value across executions.
 123 The classes associated with \glspl{SDS} are listed in
 124 Listing~\ref{lst:sdsclass}. The \CI{Main} class is introduced to box an
 125 \gls{mTask} and make it recognizable by the type system.
 126
 127 \begin{lstlisting}[%
 128         language=Clean,label={lst:sdsclass},caption={\glspl{SDS} in \gls{mTask}}]
 129 :: In a b = In infix 0 a b
 130 :: Main a = {main :: a}
 131
 132 class sds v where
 133   sds :: ((v t Upd)->In t (Main (v c s))) -> (Main (v c s)) | ...
 134 \end{lstlisting}
 135
 136 \subsection{Example \gls{mTask}}
 137 \todo{Also explain semantics about running tasks}
 138 Some example \glspl{mTask} using almost all of the functionality are show in
 139 Listing~\ref{lst:exmtask}. The \glspl{mTask} shown in the example do not belong
 140 to a particular view and therefore are of the type \CI{View t r}. The
 141 \CI{blink} \gls{mTask} show the classic \emph{Arduino} \emph{Hello World!}
 142 application that blinks a certain LED every interval. The \CI{thermostat}
 143 \gls{mTask} will enable a digital pin powering a cooling fan when the analog
 144 pin representing a temperature sensor is too high. \CI{thermostat`} shows the
 145 same program but now using the assignment style \gls{GPIO}.
 146
 147 \begin{lstlisting}[%
 148         language=Clean,label={lst:exmtask},caption={Some example \glspl{mTask}}]
 149 blink :: Main (View Int Stmt)
 150 blink = sds \x=1 In sds \led=LED1 In {main =
 151   IF (x ==. lit 1) (ledOn led) (ledOff led) :.
 152   x =. lit 1 -. x
 153   }
 154
 155 thermostat :: Main (View () Stmt)
 156 thermostat = {main =
 157   IF (analogRead A0 >. 50)
 158         ( digitalWrite D0 (lit True)  )
 159     ( digitalWrite D0 (lit False) )
 160   }
 161
 162 thermostat` :: Main (View () Stmt)
 163 thermostat` = let
 164   a0 = aIO A0
 165   d0 = dIO D0 in {main = IF (a0 >. 50) (d0 =. lit True) (d0 =. lit False) }
 166 \end{lstlisting}