1 \documentclass[../thesis.tex
]{subfiles
}
3 \input{subfilepreamble
}
7 \chapter{The
\texorpdfstring{\gls{MTASK
}}{mTask
} language
}%\texorpdfstring{\glsxtrshort{DSL}}{DSL}}%
9 \begin{chapterabstract
}
10 \noindent This chapter introduces the
\gls{TOP
} language
\gls{MTASK
} language by:
12 \item introducing the setup of the
\gls{EDSL
};
13 \item describing briefly the various interpretations;
14 \item and showing the language interface for:
17 \item expressions, datatypes, and functions;
18 \item tasks and task combinators;
19 \item and
\glspl{SDS
}.
24 The
\gls{MTASK
} system is a complete
\gls{TOP
} programming environment for programming microcontrollers.
25 This means that it not only contains a
\gls{TOP
} language but also a
\gls{TOP
} engine.
26 Due to the nature of the embedding technique, it is possible to have multiple interpretations for programs written in the
\gls{MTASK
} language.
27 As the language is implemented as an
\gls{EDSL
} in
\gls{CLEAN
} using class-based---or tagless-final---embedding (see
\cref{sec:tagless-final_embedding
}).
28 This means that the language is a collection of type classes and interpretations are data types implementing these classes.
29 Consequently, the language is extensible both in language constructs and in intepretations.
30 Adding a language construct is as simple as adding a type class and adding an interpretation is done by creating a new data type and providing implementations for the various type classes.
31 Let us illustrate this by taking the very simple language of literal values.
32 This language interface can be described using a single type constructor class with a single function
\cleaninline{lit
}.
33 This function is for lifting a values, as long as it has a
\cleaninline{toString
} instance, from the host language to our new
\gls{DSL
}.
36 class literals v where
37 lit :: a -> v a | toString a
40 Providing an evaluator is straightforward as can be seen in the following listing.
41 The evaluator is just a box holding a value of the computation but could also be some monadic computation.
46 runEval :: (Eval a) -> a
49 instance literals Eval where
53 Extending our language with a printer happens by defining a new data type and providing instances for the type constructor classes.
54 The printer stores a printed representation and hence the type is just a phantom type.
57 :: Printer a = Printer String
59 runPrinter :: (Printer a) -> String
60 runPrinter (Printer a) = a
62 instance literals Printer where
63 lit a = Printer (toString a)
66 Finally, adding language constructs happens by defining new type classes and giving implementations for some of the interpretations.
67 The following listing adds an addition construct to the language and shows implementations for the evaluator and printer.
70 class addition v where
71 add :: v a -> v a -> v a | + a
73 instance addition Eval where
74 add (Eval l) (Eval r) = Eval (l + r)
76 instance addition Printer where
77 add (Printer l) (Printer r) = Printer ("(" +++ l +++ "+" +++ r +++ ")")
80 Terms in our little toy language can be overloaded in their interpretation, they are just an interface.
81 For example, $
1+
5$ is written as
\cleaninline{add (lit
1) (lit
5)
} and has the type
\cleaninline{v Int \| literals, addition v
}.
82 \todo{hier nog uit\-leg\-gen hoe je meer\-de\-re in\-ter\-pre\-ta\-tions kunt ge\-brui\-ken?
}
84 \section{Interpretations
}
85 This section describes all
\gls{MTASK
}'s interpretations.
86 Not all of these interpretations are necessarily
\gls{TOP
} engines, i.e.\ not all of the interpretations execute the terms/tasks.
87 Some may perform an analysis over the program or typeset the program so that a textual representation can be shown.
89 \subsection{Pretty printer
}
90 This interpretation converts the expression to a string representation.
91 As the host language
\gls{CLEAN
} constructs the
\gls{MTASK
} expressions at run time, it can be useful to show the constructed expression.
92 The only function exposed for this interpretation is the
\cleaninline{showMain
} (
\cref{lst:showmain
}) function.
93 It runs the pretty printer and returns a list of strings containing the pretty printed result as shown in
\cref{lst:showexample
}.
94 The pretty printing function does the best it can but obviously cannot reproduce the layout, curried functions and variable names.
95 This shortcoming is illustrated by the example application for blinking a single
\gls{LED
} using a function and currying in
\cref{lst:showexample
}.
97 \begin{lstClean
}[caption=
{The entrypoint for the pretty printing interpretation.
},label=
{lst:showmain
}]
98 :: Show a // from the mTask Show library
99 showMain :: (Main (Show a)) ->
[String
] | type a
102 \begin{lstClean
}[caption=
{Pretty printing interpretation example.
},label=
{lst:showexample
}]
103 blinkTask :: Main (MTask v Bool) | mtask v
106 writeD d13 state >>|. delay (lit
500) >>=. blink o Not
107 ) In
{main = blink true
}
110 // fun f0 a1 = writeD(D13, a1) >>=
\a2.(delay
1000) >>| (f0 (Not a1)) in (f0 True)
113 \subsection{Simulator
}
114 The simulator converts the expression to a ready-for-work
\gls{ITASK
} simulation in which the user can inspect and control the simulated peripherals and see the internal state of the tasks.
115 The task resulting from the
\cleaninline{simulate
} function presents the user with an interactive simulation environment (see
\cref{lst:simulatemain,fig:sim
}).
116 From within the interactive application, tasks can be (partly) executed, peripheral states changed and
\glspl{SDS
} interacted with.
118 \begin{lstClean
}[caption=
{The entrypoint for the simulation interpretation.
},label=
{lst:simulatemain
}]
119 :: TraceTask a // from the mTask Show library
120 simulate :: (Main (TraceTask a)) ->
[String
] | type a
125 \includegraphics[width=
\linewidth]{simg
}
126 \caption{Simulator interface for the blink program.
}\label{fig:sim
}
129 \subsection{Byte code compiler
}
130 The main interpretation of the
\gls{MTASK
} system is the byte code compiler.
131 With it, and a handful of integration functions and tasks,
\gls{MTASK
} tasks can be executed on microcontrollers and integrated in
\gls{ITASK
} as if they were regular
\gls{ITASK
} tasks.
132 Furthermore, with a special language construct,
\glspl{SDS
} can be shared between
\gls{MTASK
} and
\gls{ITASK
} programs as well.
133 This interface is explained thoroughly in
\cref{chp:integration_with_itask
}.
135 When using the byte code compiler interpretation in conjunction with the
\gls{ITASK
} integration,
\gls{MTASK
} is a heterogeneous
\gls{DSL
}.
136 I.e.\ some components---for example the
\gls{RTS
} on the microcontroller---is largely unaware of the other components in the system, and it is executed on a completely different architecture.
137 The
\gls{MTASK
} language is an enriched simply-typed $
\lambda$-calculus with support for some basic types, arithmetic operations, and function definition; and a task language (see
\cref{sec:top
}).
140 To leverage the type checker of the host language, types in the
\gls{MTASK
} language are expressed as types in the host language, to make the language type safe.
141 However, not all types in the host language are suitable for microcontrollers that may only have
\qty{2}{\kibi\byte} of
\gls{RAM
} so class constraints are therefore added to the
\gls{DSL
} functions.
142 The most used class constraint is the
\cleaninline{type
} class collection containing functions for serialization, printing,
\gls{ITASK
} constraints,
\etc.
143 Many of these functions can be derived using generic programming.
144 An even stronger restriction on types is defined for types that have a stack representation.
145 This
\cleaninline{basicType
} class has instances for many
\gls{CLEAN
} basic types such as
\cleaninline{Int
},
\cleaninline{Real
} and
\cleaninline{Bool
}.
146 The class constraints for values in
\gls{MTASK
} are omnipresent in all functions and therefore often omitted throughout throughout the chapters for brevity and clarity.
150 \caption{Translation from
\gls{CLEAN
}\slash\gls{MTASK
} data types to
\ccpp{} datatypes.
}%
151 \label{tbl:mtask-c-datatypes
}
154 \gls{CLEAN
}\slash\gls{MTASK
} &
\ccpp{} type &
\textnumero{}bits\\
156 \cleaninline{Bool
} &
\cinline{bool
} &
16\\
157 \cleaninline{Char
} &
\cinline{char
} &
16\\
158 \cleaninline{Int
} &
\cinline{int16_t
} &
16\\
159 \cleaninline{Real
} &
\cinline{float
} &
32\\
160 \cleaninline{:: Long
} &
\cinline{int32_t
} &
32\\
161 \cleaninline{:: T = A \| B \| C
} &
\cinline{enum
} &
16\\
166 \Cref{lst:constraints
} contains the definitions for the auxiliary types and type constraints (such as
\cleaninline{type
} and
\cleaninline{basicType
}) that are used to construct
\gls{MTASK
} expressions.
167 The
\gls{MTASK
} language interface consists of a core collection of type classes bundled in the type class
\cleaninline{class mtask
}.
168 Every interpretation implements the type classes in the
\cleaninline{mtask
} class
169 There are also
\gls{MTASK
} extensions that not every interpretation implements such as peripherals and
\gls{ITASK
} integration.
170 \begin{lstClean
}[caption=
{Classes and class collections for the
\gls{MTASK
} language.
},label=
{lst:constraints
}]
171 class type t | iTask, ... ,fromByteCode, toByteCode t
172 class basicType t | type t where ...
174 class mtask v | expr, ..., int, real, long v
177 Sensors,
\glspl{SDS
}, functions,
\etc{} may only be defined at the top level.
178 The
\cleaninline{Main
} type is used that is used to distinguish the top level from the main expression.
179 Some top level definitions, such as functions, are defined using
\gls{HOAS
}.
180 To make their syntax friendlier, the
\cleaninline{In
} type---an infix tuple---is used to combine these top level definitions as can be seen in
\cleaninline{someTask
} (
\cref{lst:mtask_types
}).
182 \begin{lstClean
}[caption=
{Example task and auxiliary types in the
\gls{MTASK
} language.
},label=
{lst:mtask_types
}]
183 :: Main a =
{ main :: a
}
184 :: In a b = (In) infix
0 a b
186 someTask :: MTask v Int | mtask v & liftsds v & sensor1 v & ...
188 sensor1 config1
\sns1->
189 sensor2 config2
\sns2->
190 sds
\s1 = initialValue
191 In liftsds
\s2 = someiTaskSDS
192 In fun
\fun1= ( ... )
193 In fun
\fun2= ( ... )
194 In
{ main = mainexpr
}
197 \Gls{MTASK
} expressions are usually overloaded in their interpretation (
\cleaninline{v
}).
198 In
\gls{CLEAN
}, all free variables in a type are implicitly universally quantified.
199 In order to use the
\gls{MTASK
} expressions with multiple interpretations, rank-
2 polymorphism is required
\citep{odersky_putting_1996
}\citep[\citesection{3.7.4}]{plasmeijer_clean_2021
}.
200 \Cref{lst:rank2_mtask
} shows an example of a function that simulates an
\gls{MTASK
} expression while showing the pretty printed representation in parallel.
201 Providing a type for the
\cleaninline{simulateAndPrint
} function is mandatory as the compiler cannot infer the type of rank-
2 polymorphic functions.
203 \begin{lstClean
}[label=
{lst:rank2_mtask
},caption=
{Rank-
2 polymorphism to allow multiple interpretations
}]
204 prettyPrint :: Main (MTask PrettyPrint a) -> String
205 simulate :: Main (MTask Simulate a) -> Task a
207 simulateAndPrint :: (A.v: Main (MTask v a) | mtask v) -> Task a | type a
208 simulateAndPrint mt =
210 -|| Hint "Current task:" @>> viewInformation
[] (prettyPrint mt)
213 \section{Expressions
}\label{sec:expressions
}
214 This section shows all
\gls{MTASK
} constructs for exppressions.
215 \Cref{lst:expressions
} shows the
\cleaninline{expr
} class containing the functionality to lift values from the host language to the
\gls{MTASK
} language (
\cleaninline{lit
}); perform number and boolean arithmetics; do comparisons; and conditional execution.
216 For every common boolean and arithmetic operator in the host language, an
\gls{MTASK
} variant is present, suffixed by a period to not clash with
\gls{CLEAN
}'s builtin operators.
218 \begin{lstClean
}[caption=
{The
\gls{MTASK
} class for expressions
},label=
{lst:expressions
}]
220 lit :: t -> v t | type t
221 (+.) infixl
6 :: (v t) (v t) -> v t | basicType, +, zero t
223 (&.) infixr
3 :: (v Bool) (v Bool) -> v Bool
224 (|.) infixr
2 :: (v Bool) (v Bool) -> v Bool
225 Not :: (v Bool) -> v Bool
226 (==.) infix
4 :: (v a) (v a) -> v Bool | Eq, basicType a
228 If :: (v Bool) (v t) (v t) -> v t | type t
231 Conversion to-and-fro data types is available through the overloaded functions
\cleaninline{int
},
\cleaninline{long
} and
\cleaninline{real
} that will convert the argument to the respective type similar to casting in
\gls{C
}.
232 For most interpretations, there are instances of these classes for all numeric types.
234 \begin{lstClean
}[caption=
{Type conversion functions in
\gls{MTASK
}.
}]
235 class int v a :: (v a) -> v Int
236 class real v a :: (v a) -> v Real
237 class long v a :: (v a) -> v Long
240 Values from the host language must be explicitly lifted to the
\gls{MTASK
} language using the
\cleaninline{lit
} function.
241 For convenience, there are many lower-cased macro definitions for often used constants such as
\cleaninline{true :== lit True
},
\cleaninline{false :== lit False
},
\etc.
243 \Cref{lst:example_exprs
} shows some examples of these expressions.
244 Since they are only expressions, there is no need for a
\cleaninline{Main
}.
245 \cleaninline{e0
} defines the literal $
42$,
\cleaninline{e1
} calculates the literal $
42.0$ using real numbers.
246 \cleaninline{e2
} compares
\cleaninline{e0
} and
\cleaninline{e1
} as integers and if they are equal it returns the
\cleaninline{e2
}$/
2$ and
\cleaninline{e0
} otherwise.
248 \begin{lstClean
}[label=
{lst:example_exprs
},caption=
{Example
\gls{MTASK
} expressions.
}]
252 e1 :: v Real | expr v
253 e1 = lit
38.0 + real (lit
4)
256 e2 = if' (e0 ==. int e1)
260 \Gls{MTASK
} is shallowly embedded in
\gls{CLEAN
} and the terms are constructed at runtime.
261 This means that
\gls{MTASK
} programs can also be tailor-made at runtime or constructed using
\gls{CLEAN
} functions maximising the linguistic reuse
\citep{krishnamurthi_linguistic_2001
}
262 \cleaninline{approxEqual
} in
\cref{lst:example_macro
} performs a simple approximate equality---albeit without taking into account all floating point pecularities.
263 When calling
\cleaninline{approxEqual
} in an
\gls{MTASK
} function, the resulting code is inlined.
265 \begin{lstClean
}[label=
{lst:example_macro
},caption=
{Example linguistic reuse in the
\gls{MTASK
} language.
}]
266 approxEqual :: (v Real) (v Real) (v Real) -> v Real | expr v
267 approxEqual x y eps = if' (x ==. y) true
274 \subsection{Data types
}
275 Most of
\gls{CLEAN
}'s fixed-size basic types are mapped on
\gls{MTASK
} types.
276 However, it can be useful to have access to compound types as well.
277 All types in
\gls{MTASK
} must have a fixed size representation on the stack so sum types are not (yet) supported.
278 While it is possible to lift types using the
\cleaninline{lit
} function, you cannot do anything with the types besides passing them around but they are being produced by some parallel task combinators (see
\cref{sssec:combinators_parallel
}).
279 To be able to use types as first class citizens, constructors and field selectors are required (see
\cref{chp:first-class_datatypes
}).
280 \Cref{lst:tuple_exprs
} shows the scaffolding for supporting tuples in
\gls{MTASK
}.
281 Besides the constructors and field selectors, there is also a helper function available that transforms a function from a tuple of
\gls{MTASK
} expressions to an
\gls{MTASK
} expression of a tuple.
282 Examples for using tuple can be found in
\cref{sec:mtask_functions
}.
284 \begin{lstClean
}[label=
{lst:tuple_exprs
},caption=
{Tuple constructor and field selectors in
\gls{MTASK
}.
}]
286 tupl :: (v a) (v b) -> v (a, b) | type a & type b
287 first :: (v (a, b)) -> v a | type a & type b
288 second :: (v (a, b)) -> v b | type a & type b
290 tupopen f :==
\v->f (first v, second v)
293 \subsection{Functions
}\label{sec:mtask_functions
}
294 Adding functions to the language is achieved by type class to the
\gls{DSL
}.
295 By using
\gls{HOAS
}, both the function definition and the calls to the function can be controlled by the
\gls{DSL
} \citep{pfenning_higher-order_1988,chlipala_parametric_2008
}.
296 The
\gls{MTASK
} only allows first-order functions and does not allow partial function application.
297 This is restricted by using a multi-parameter type class where the first parameter represents the arguments and the second parameter the view.
298 By providing a single instance per function arity instead of providing one instance for all functions and using tuples for the arguments this constraint can be enforced.
299 Also,
\gls{MTASK
} only supports top-level functions which is enforced by the
\cleaninline{Main
} box.
300 The definition of the type class and the instances for an example interpretation (
\cleaninline{:: Inter
}) are as follows:
302 \begin{lstClean
}[caption=
{Functions in
\gls{MTASK
}.
}]
303 class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u)))
306 instance fun () Inter where ...
307 instance fun (Inter a) Inter | type a where ...
308 instance fun (Inter a, Inter b) Inter | type a, type b where ...
309 instance fun (Inter a, Inter b, Inter c) Inter | type a, ... where ...
313 Deriving how to define and use functions from the type is quite the challenge even though the resulting syntax is made easier using the infix type
\cleaninline{In
}.
314 \Cref{lst:function_examples
} show the factorial function, a tail-call optimised factorial function and a function with zero arguments to demonstrate the syntax.
315 Splitting out the function definition for each single arity means that that for every function arity and combination of arguments, a separate class constraint must be created.
316 Many of the often used functions are already bundled in the
\cleaninline{mtask
} class constraint collection.
317 \cleaninline{factorialtail
} shows a manually added class constraint.
318 Definiting zero arity functions is shown in the
\cleaninline{zeroarity
} expression.
319 Finally,
\cleaninline{swapTuple
} shows an example of a tuple being swapped.
321 % VimTeX: SynIgnore on
322 \begin{lstClean
}[label=
{lst:function_examples
},caption=
{Function examples in
\gls{MTASK
}.
}]
323 factorial :: Main (v Int) | mtask v
325 fun
\fac=(
\i->if' (i <. lit
1)
327 (i *. fac (i -. lit
1)))
328 In
{main = fac (lit
5)
}
330 factorialtail :: Main (v Int) | mtask v & fun (v Int, v Int) v
332 fun
\facacc=(\(acc, i)->if' (i <. lit
1)
334 (fac (acc *. i, i -. lit
1)))
335 In fun
\fac=(
\i->facacc (lit
1, i))
336 In
{main = fac (lit
5)
}
338 zeroarity :: Main (v Int) | mtask v
340 fun
\fourtytwo=(\()->lit
42)
341 In fun
\add=(\(x, y)->x +. y)
342 In
{main = add (fourtytwo (), lit
9)
}
344 swapTuple :: Main (v (Int, Bool)) | mtask v
346 fun
\swap=(tupopen \(x, y)->tupl y x)
347 In
{main = swap (tupl true (lit
42))
}
349 % VimTeX: SynIgnore off
351 \section{Tasks and task combinators
}\label{sec:top
}
352 This section describes
\gls{MTASK
}'s task language.
353 \Gls{MTASK
}'s task language can be divided into three categories, namely
355 \item Basic tasks, in most
\gls{TOP
} systems, the basic tasks are called editors, modelling the interactivity with the user.
356 In
\gls{MTASK
}, there are no
\emph{editors
} in that sense but there is interaction with the outside world through microcontroller peripherals such as sensors and actuators.
357 \item Task combinators provide a way of describing the workflow.
358 They combine one or more tasks into a compound task.
359 \item \glspl{SDS
} in
\gls{MTASK
} can be seen as references to data that can be shared using many-to-many communication and are only accessible from within the task language to ensure atomicity.
362 As
\gls{MTASK
} is integrated with
\gls{ITASK
}, the same stability distinction is made for task values.
363 A task in
\gls{MTASK
} is denoted by the
\gls{DSL
} type synonym shown in
\cref{lst:task_type
}, an expression of the type
\cleaninline{TaskValue a
} in interpretation
\cleaninline{v
}.
365 \begin{lstClean
}[label=
{lst:task_type
},caption=
{Task type in
\gls{MTASK
}.
}]
366 :: MTask v a :== v (TaskValue a)
368 // From the iTask library
374 \subsection{Basic tasks
}
375 The most rudimentary basic tasks are the
\cleaninline{rtrn
} and
\cleaninline{unstable
} tasks.
376 They lift the value from the
\gls{MTASK
} expression language to the task domain either as a stable value or an unstable value.
377 There is also a special type of basic task for delaying execution.
378 The
\cleaninline{delay
} task---given a number of milliseconds---yields an unstable value while the time has not passed.
379 Once the specified time has passed, the time it overshot the planned time is yielded as a stable task value.
380 See
\cref{sec:repeat
} for an example task using
\cleaninline{delay
}.
382 \begin{lstClean
}[label=
{lst:basic_tasks
},caption=
{Function examples in
\gls{MTASK
}.
}]
383 class rtrn v :: (v t) -> MTask v t
384 class unstable v :: (v t) -> MTask v t
385 class delay v :: (v n) -> MTask v n | long v n
388 \subsubsection{Peripherals
}\label{sssec:peripherals
}
389 For every sensor or actuator, basic tasks are available that allow interaction with the specific peripheral.
390 The type classes for these tasks are not included in the
\cleaninline{mtask
} class collection as not all devices nor all language interpretations have such peripherals connected.
392 \Cref{lst:dht,lst:gpio
} show the type classes for
\glspl{DHT
} sensors and
\gls{GPIO
} access.
393 Other peripherals have similar interfaces, they are available in the
\cref{sec:aux_peripherals
}.
394 For the
\gls{DHT
} sensor there are two basic tasks,
\cleaninline{temperature
} and
\cleaninline{humidity
}, that---will given a
\cleaninline{DHT
} object---produce a task that yields the observed temperature in
\unit{\celcius} or relative humidity as a percentage as an unstable value.
395 Currently, two different types of
\gls{DHT
} sensors are supported, the
\emph{DHT
} family of sensors connect through $
1$-wire protocol and the
\emph{SHT
} family of sensors connected using
\gls{I2C
} protocol.
396 Creating such a
\cleaninline{DHT
} object is very similar to creating functions in
\gls{MTASK
} and uses
\gls{HOAS
} to make it type safe.
398 \begin{lstClean
}[label=
{lst:dht
},caption=
{The
\gls{MTASK
} interface for
\glspl{DHT
} sensors.
}]
401 = DHT_DHT Pin DHTtype
403 :: DHTtype = DHT11 | DHT21 | DHT22
405 DHT :: DHTInfo ((v DHT) -> Main (v b)) -> Main (v b) | type b
406 temperature :: (v DHT) -> MTask v Real
407 humidity :: (v DHT) -> MTask v Real
409 measureTemp :: Main (MTask v Real) | mtask v & dht v
410 measureTemp = DHT (DHT_SHT (i2c
0x36))
\dht->
411 {main=temperature dht
}
414 \Gls{GPIO
} access is divided into three classes: analog, digital and pin modes (see
\cref{lst:gpio
}).
415 For all pins and pin modes an
\gls{ADT
} is available that enumerates the pins.
416 The analog
\gls{GPIO
} pins of a microcontroller are connected to an
\gls{ADC
} that translates the voltage to an integer.
417 Analog
\gls{GPIO
} pins can be either read or written to.
418 Digital
\gls{GPIO
} pins only
report a high or a low value.
419 The
\cleaninline{pin
} type class allows functions to be overloaded in either the analog or digital pins, e.g.\ analog pins can be considered as digital pins as well.
421 For digital
\gls{GPIO
} interaction, the
\cleaninline{dio
} type class is used.
422 The first argument of the functions in this class is overloaded, i.e.\ it accepts either an
\cleaninline{APin
} or a
\cleaninline{DPin
}.
423 Analog
\gls{GPIO
} tasks are bundled in the
\cleaninline{aio
} type class.
424 \Gls{GPIO
} pins usually operate according to a certain pin mode that states whether the pin acts as an input pin, an input with an internal pull-up resistor or an output pin.
425 This setting can be applied using the
\cleaninline{pinMode
} class by hand or by using the
\cleaninline{declarePin
} \gls{GPIO
} pin constructor.
426 Setting the pin mode is a task that immediately finisheds and fields a stable unit value.
427 Writing to a pin is also a task that immediately finishes but yields the written value instead.
428 Reading a pin is a task that yields an unstable value---i.e.\ the value read from the actual pin.
430 \begin{lstClean
}[label=
{lst:gpio
},caption=
{The
\gls{MTASK
} interface for
\gls{GPIO
} access.
}]
431 :: APin = A0 | A1 | A2 | A3 | A4 | A5
432 :: DPin = D0 | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | ...
433 :: PinMode = PMInput | PMOutput | PMInputPullup
434 :: Pin = AnalogPin APin | DigitalPin DPin
436 class pin p :: p -> Pin
437 instance pin APin, DPin
440 writeA :: (v APin) (v Int) -> MTask v Int
441 readA :: (v APin) -> MTask v Int
443 class dio p v | pin p where
444 writeD :: (v p) (v Bool) -> MTask v Bool
445 readD :: (v p) -> MTask v Bool | pin p
447 class pinMode v where
448 pinMode :: (v PinMode) (v p) -> MTask v () | pin p
449 declarePin :: p PinMode ((v p) -> Main (v a)) -> Main (v a) | pin p
452 \Cref{lst:gpio_examples
} shows two examples of
\gls{MTASK
} tasks using
\gls{GPIO
} pins.
453 \cleaninline{task1
} reads analog
\gls{GPIO
} pin
3.
454 This is a task that never terminates.
455 \cleaninline{task2
} writes the
\cleaninline{true
} (
\gls{ARDUINO
} \arduinoinline{HIGH
}) value to digital
\gls{GPIO
} pin
3.
456 This task finishes immediately after writing to the pin.
458 \begin{lstClean
}[label=
{lst:gpio_examples
},caption=
{\Gls{GPIO
} example in
\gls{MTASK
}.
}]
459 task1 :: MTask v Int | mtask v
460 task1 = declarePin A3 PMInput
\a3->
{main=readA a3
}
462 task2 :: MTask v Int | mtask v
463 task2 = declarePin D3 PMOutput
\d3->
{main=writeD d3 true
}
466 \subsection{Task combinators
}
467 Task combinators are used to combine multiple tasks to describe workflows.
468 In contrast to
\gls{ITASK
}, that uses super combinators to derive the simpler ones,
\gls{MTASK
} has a set of simpler combinators from which more complicated workflow can be derived.
469 There are three main types of task combinators, namely:
471 \item Sequential combinators that execute tasks one after the other, possibly using the result of the left hand side.
472 \item Parallel combinators that execute tasks at the same time combining the result.
473 \item Miscellaneous combinators that change the semantics of a task---e.g.\ repeat it or delay execution.
476 \subsubsection{Sequential
}
477 Sequential task combination allows the right-hand side task to observe the left-hand side task value.
478 All seqential task combinators are expressed in the
\cleaninline{expr
} class and can be---and are by default---derived from the Swiss army knife step combinator
\cleaninline{>>*.
}.
479 This combinator has a single task on the left-hand side and a list of
\emph{task continuations
} on the right-hand side.
480 The list of task continuations is checked every rewrite step and if one of the predicates matches, the task continues with the result of this combination.
481 \cleaninline{>>=.
} is a shorthand for the bind operation, if the left-hand side is stable, the right-hand side function is called to produce a new task.
482 \cleaninline{>>\|.
} is a shorthand for the sequence operation, if the left-hand side is stable, it continues with the right-hand side task.
483 The
\cleaninline{>>~.
} and
\cleaninline{>>..
} combinators are variants of the ones above that ignore the stability and continue on an unstable value as well.
485 \begin{lstClean
}[label=
{lst:mtask_sequential
},caption=
{Sequential task combinators in
\gls{MTASK
}.
}]
486 class step v | expr v where
487 (>>*.) infixl
1 :: (MTask v t)
[Step v t u
] -> MTask v u
488 (>>=.) infixl
0 :: (MTask v t) ((v t) -> MTask v u) -> MTask v u
489 (>>|.) infixl
0 :: (MTask v t) (MTask v u) -> MTask v u
490 (>>~.) infixl
0 :: (MTask v t) ((v t) -> MTask v u) -> MTask v u
491 (>>..) infixl
0 :: (MTask v t) (MTask v u) -> MTask v u
494 = IfValue ((v t) -> v Bool) ((v t) -> MTask v u)
495 | IfStable ((v t) -> v Bool) ((v t) -> MTask v u)
496 | IfUnstable ((v t) -> v Bool) ((v t) -> MTask v u)
500 The following listing shows an example of a step in action.
501 The
\cleaninline{readPinBin
} function produces an
\gls{MTASK
} task that classifies the value of an analogue pin into four bins.
502 It also shows that the nature of embedding allows the host language to be used as a macro language.
505 \begin{lstClean
}[label=
{lst:mtask_readpinbin
},caption=
{Read an analog pin and bin the value in
\gls{MTASK
}.
}]
506 readPinBin :: Int -> Main (MTask v Int) | mtask v
507 readPinBin lim = declarePin PMInput A2
\a2->
508 { main = readA a2 >>*.
509 [ IfValue (
\x->x <. lim) (
\_->rtrn (lit bin))
510 \\ lim <-
[64,
128,
192,
256]
514 \subsubsection{Parallel
}\label{sssec:combinators_parallel
}
515 The result of a parallel task combination is a compound that actually executes the tasks at the same time.
516 There are two types of parallel task combinators (see
\cref{lst:mtask_parallel
}).
518 \begin{lstClean
}[label=
{lst:mtask_parallel
},caption=
{Parallel task combinators in
\gls{MTASK
}.
}]
519 class (.&&.) infixr
4 v :: (MTask v a) (MTask v b) -> MTask v (a, b)
520 class (.||.) infixr
3 v :: (MTask v a) (MTask v a) -> MTask v a
523 The conjunction combinator (
\cleaninline{.&&.
}) combines the result by putting the values from both sides in a tuple.
524 The stability of the task depends on the stability of both children.
525 If both children are stable, the result is stable, otherwise the result is unstable.
526 The disjunction combinator (
\cleaninline{.\|\|.
}) combines the results by picking the leftmost, most stable task.
527 The semantics are most easily described using the
\gls{CLEAN
} functions shown in
\cref{lst:semantics_con,lst:semantics_dis
}.
531 \begin{subfigure
}[t
]{.5\textwidth}
532 \begin{lstClean
}[caption=
{Semantics of the\
\conjunction combinator.
},label=
{lst:semantics_con
}]
533 con :: (TaskValue a) (TaskValue b)
535 con NoValue r = NoValue
536 con l NoValue = NoValue
537 con (Value l ls) (Value r rs)
538 = Value (l, r) (ls && rs)
542 \begin{subfigure
}[t
]{.5\textwidth}
543 \begin{lstClean
}[caption=
{Semantics of the\
\disjunction combinator.
},label=
{lst:semantics_dis
}]
544 dis :: (TaskValue a) (TaskValue a)
548 dis (Value l ls) (Value r rs)
550 | otherwise = Value l ls
555 \Cref{lst:mtask_parallel_example
} gives an example program using the parallel task combinator.
556 This program will read two pins at the same time, returning when one of the pins becomes
\arduinoinline{HIGH
}.
557 If the combinator was the
\cleaninline{.&&.
} instead, the type would be
\cleaninline{MTask v (Bool, Bool)
} and the task would only return when both pins have been
\arduinoinline{HIGH
} but not necessarily at the same time.
559 \begin{lstClean
}[label=
{lst:mtask_parallel_example
},caption=
{Parallel task combinator example in
\gls{MTASK
}.
}]
562 declarePin D0 PMInput
\d0->
563 declarePin D1 PMInput
\d1->
564 let monitor pin = readD pin >>*.
[IfValue (
\x->x)
\x->rtrn x
]
565 In
{main = monitor d0 .||. monitor d1
}
568 \subsubsection{Repeat
}\label{sec:repeat
}
569 The
\cleaninline{rpeat
} combinator executes the child task.
570 If a stable value is observed, the task is reinstated.
571 The functionality of
\cleaninline{rpeat
} can also be simulated by using functions and sequential task combinators and even made to be stateful as can be seen in
\cref{lst:blinkthreadmtask
}.
573 \begin{lstClean
}[label=
{lst:mtask_repeat
},caption=
{Repeat task combinators in
\gls{MTASK
}.
}]
575 rpeat :: (MTask v a) -> MTask v a
578 To demonstrate the combinator,
\cref{lst:mtask_repeat_example
} show
\cleaninline{rpeat
} in use.
579 This task will mirror the value read from analog
\gls{GPIO
} pin
\cleaninline{A1
} to pin
\cleaninline{A2
} by constantly reading the pin and writing the result.
581 \begin{lstClean
}[label=
{lst:mtask_repeat_example
},caption=
{Exemplary repeat task in
\gls{MTASK
}.
}]
582 task :: MTask v Int | mtask v
584 declarePin A1 PMInput
\a1->
585 declarePin A2 PMOutput
\a2->
586 {main = rpeat (readA a1 >>~. writeA a2 >>|. delay (lit
1000))
}
589 \subsection{\texorpdfstring{\Glsxtrlongpl{SDS
}}{Shared data sources
}}
590 \Glspl{SDS
} in
\gls{MTASK
} are by default references to shared memory but can also be references to
\glspl{SDS
} in
\gls{ITASK
} (see
\cref{sec:liftsds
}).
591 Similar to peripherals (see
\cref{sssec:peripherals
}), they are constructed at the top level and are accessed through interaction tasks.
592 The
\cleaninline{getSds
} task yields the current value of the
\gls{SDS
} as an unstable value.
593 This behaviour is similar to the
\cleaninline{watch
} task in
\gls{ITASK
}.
594 Writing a new value to
\pgls{SDS
} is done using
\cleaninline{setSds
}.
595 This task yields the written value as a stable result after it is done writing.
596 Getting and immediately after setting
\pgls{SDS
} is not necessarily an
\emph{atomic
} operation in
\gls{MTASK
} because it is possible that another task accesses the
\gls{SDS
} in between.
597 To circumvent this issue,
\cleaninline{updSds
} is created, this task atomically updates the value of the
\gls{SDS
}.
598 The
\cleaninline{updSds
} task only guarantees atomicity within
\gls{MTASK
}.
600 \begin{lstClean
}[label=
{lst:mtask_sds
},caption=
{\Glspl{SDS
} in
\gls{MTASK
}.
}]
603 sds :: ((v (Sds t)) -> In t (Main (MTask v u))) -> Main (MTask v u)
604 getSds :: (v (Sds t)) -> MTask v t
605 setSds :: (v (Sds t)) (v t) -> MTask v t
606 updSds :: (v (Sds t)) ((v t) -> v t) -> MTask v t
609 \Cref{lst:mtask_sds_examples
} shows an example using
\glspl{SDS
}.
610 The
\cleaninline{count
} function takes a pin and returns a task that counts the number of times the pin is observed as high by incrementing the
\cleaninline{share
} \gls{SDS
}.
611 In the
\cleaninline{main
} expression, this function is called twice and the results are combined using the parallel or combinator (
\cleaninline{.\|\|.
}).
612 Using a sequence of
\cleaninline{getSds
} and
\cleaninline{setSds
} would be unsafe here because the other branch might write their old increment value immediately after writing, effectively missing a count.
\todo{beter opschrijven
}
614 \begin{lstClean
}[label=
{lst:mtask_sds_examples
},caption=
{Examples with
\glspl{SDS
} in
\gls{MTASK
}.
}]
615 task :: MTask v Int | mtask v
616 task = declarePin D3 PMInput
\d3->
617 declarePin D5 PMInput
\d5->
619 In fun
\count=(
\pin->
621 >>*
[IfValue (
\x->x) (
\_->updSds (
\x->x +. lit
1) share)
]
622 >>| delay (lit
100) // debounce
624 In
{main=count d3 .||. count d5
}
628 \Gls{MTASK
} is a rich
\gls{TOP
} language tailored for
\gls{IOT
} systems.
629 It is embedded in the pure functional language
\gls{CLEAN
} and uses an enriched lambda calculus as a host language.
630 It provides support for all common arithmetic expressions, conditionals, functions, but also several basic tasks, task combinators, peripheral support and integration with
\gls{ITASK
}.
631 By embedding domain-specific knowledge in the language itself, it achieves the same abstraction level and dynamicity as other
\gls{TOP
} languages while targetting tiny computers instead.
632 As a result, a single declarative specification can describe an entire
\gls{IOT
} system.
634 \input{subfilepostamble
}