1 \documentclass[../thesis.tex
]{subfiles
}
3 \input{subfilepreamble
}
8 \chapter{The
\texorpdfstring{\gls{MTASK
}}{mTask
} language
}%\texorpdfstring{\glsxtrshort{DSL}}{DSL}}%
10 \begin{chapterabstract
}
11 \noindent This chapter introduces the
\gls{TOP
} language
\gls{MTASK
} language by:
13 \item introducing the setup of the
\gls{EDSL
};
14 \item and showing the language interface and examples for the type system, data types, expressions, tasks and their combinators.
18 The
\gls{MTASK
} system is a complete
\gls{TOP
} programming environment for programming microcontrollers, i.e.\ it contains a
\gls{TOP
} language and a
\gls{TOP
} engine.
19 It is implemented as an
\gls{EDSL
} in
\gls{CLEAN
} using class-based---or tagless-final---embedding (see
\cref{sec:tagless-final_embedding
}).
20 Due to the nature of the embedding technique, it is possible to have multiple interpretations for programs written in the
\gls{MTASK
} language.
21 The following interpretations are available for
\gls{MTASK
}.
26 This interpretation converts the expression to a string representation.
29 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.
30 \item[Byte code compiler
]
32 The compiler compiles the
\gls{MTASK
} program to a specialised byte code.
33 Using a handful of integration functions and tasks (see
\cref{chp:integration_with_itask
}),
\gls{MTASK
} tasks can be executed on microcontrollers and integrated in
\gls{ITASK
} as if they were regular
\gls{ITASK
} tasks.
34 Furthermore, with special language constructs,
\glspl{SDS
} can be shared between
\gls{MTASK
} and
\gls{ITASK
} programs.
37 When using the compiler interpretation in conjunction with the
\gls{ITASK
} integration,
\gls{MTASK
} is a heterogeneous
\gls{DSL
}.
38 I.e.\ some components---e.g.\ 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.
39 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
}).
42 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.
43 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.
44 The most used class constraint is the
\cleaninline{type
} class collection containing functions for serialization, printing,
\gls{ITASK
} constraints,
\etc.
45 Many of these functions can be derived using generic programming.
46 An even stronger restriction on types is defined for types that have a stack representation.
47 This
\cleaninline{basicType
} class has instances for many
\gls{CLEAN
} basic types such as
\cleaninline{Int
},
\cleaninline{Real
} and
\cleaninline{Bool
}.
48 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.
52 \caption{Mapping from
\gls{CLEAN
}/
\gls{MTASK
} data types to
\gls{CPP
} datatypes.
}%
53 \label{tbl:mtask-c-datatypes
}
56 \gls{CLEAN
}/
\gls{MTASK
} &
\gls{CPP
} type &
\textnumero{}bits\\
58 \cleaninline{Bool
} &
\cinline{bool
} &
16\\
59 \cleaninline{Char
} &
\cinline{char
} &
16\\
60 \cleaninline{Int
} &
\cinline{int16_t
} &
16\\
61 \cleaninline{:: Long
} &
\cinline{int32_t
} &
32\\
62 \cleaninline{Real
} &
\cinline{float
} &
32\\
63 \cleaninline{:: T = A \| B \| C
} &
\cinline{enum
} &
16\\
68 \Cref{lst:constraints
} contains the definitions for the auxiliary types and type constraints (such as
\cleaninline{type
} an
\cleaninline{basicType
}) that are used to construct
\gls{MTASK
} expressions.
69 The
\gls{MTASK
} language interface consists of a core collection of type classes bundled in the type class
\cleaninline{class mtask
}.
70 Every interpretation implements the type classes in the
\cleaninline{mtask
} class
71 There are also
\gls{MTASK
} extensions that not every interpretation implements such as peripherals and
\gls{ITASK
} integration.
72 \begin{lstClean
}[caption=
{Classes and class collections for the
\gls{MTASK
} language.
},label=
{lst:constraints
}]
73 class type t | iTask, ... ,fromByteCode, toByteCode t
74 class basicType t | type t where ...
76 class mtask v | expr, ..., int, real, long v
79 Sensors,
\glspl{SDS
}, functions,
\etc{} may only be defined at the top level.
80 The
\cleaninline{Main
} type is used that is used to distinguish the top level from the main expression.
81 Some top level definitions, such as functions, are defined using
\gls{HOAS
}.
82 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
}).
84 \begin{lstClean
}[caption=
{Example task and auxiliary types in the
\gls{MTASK
} language.
},label=
{lst:mtask_types
}]
85 :: Main a =
{ main :: a
}
86 :: In a b = (In) infix
0 a b
88 someTask :: MTask v Int | mtask v & liftsds v & sensor1 v & ...
90 sensor1 config1
\sns1->
91 sensor2 config2
\sns2->
92 sds
\s1 = initialValue
93 In liftsds
\s2 = someiTaskSDS
96 In
{ main = mainexpr
}
99 \section{Expressions
}\label{sec:expressions
}
100 This section shows all
\gls{MTASK
} constructs for exppressions.
101 \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.
102 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.
104 \begin{lstClean
}[caption=
{The
\gls{MTASK
} class for expressions
},label=
{lst:expressions
}]
106 lit :: t -> v t | type t
107 (+.) infixl
6 :: (v t) (v t) -> v t | basicType, +, zero t
109 (&.) infixr
3 :: (v Bool) (v Bool) -> v Bool
110 (|.) infixr
2 :: (v Bool) (v Bool) -> v Bool
111 Not :: (v Bool) -> v Bool
112 (==.) infix
4 :: (v a) (v a) -> v Bool | Eq, basicType a
114 If :: (v Bool) (v t) (v t) -> v t | type t
117 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
}.
119 \begin{lstClean
}[caption=
{Type conversion functions in
\gls{MTASK
}.
}]
120 class int v a :: (v a) -> v Int
121 class real v a :: (v a) -> v Real
122 class long v a :: (v a) -> v Long
125 Values from the host language must be explicitly lifted to the
\gls{MTASK
} language using the
\cleaninline{lit
} function.
126 For convenience, there are many lower-cased macro definitions for often used constants such as
\cleaninline{true :== lit True
},
\cleaninline{false :== lit False
},
\etc.
128 \Cref{lst:example_exprs
} shows some examples of these expressions.
129 Since they are only expressions, there is no need for a
\cleaninline{Main
}.
130 \cleaninline{e0
} defines the literal $
42$,
\cleaninline{e1
} calculates the literal $
42.0$ using real numbers.
131 \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.
133 \begin{lstClean
}[label=
{lst:example_exprs
},caption=
{Example
\gls{MTASK
} expressions.
}]
137 e1 :: v Real | expr v
138 e1 = lit
38.0 + real (lit
4)
141 e2 = if' (e0 ==. int e1)
145 \Gls{MTASK
} is shallowly embedded in
\gls{CLEAN
} and the terms are constructed at runtime.
146 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
}
147 \cleaninline{approxEqual
} in
\cref{lst:example_macro
} performs a simple approximate equality---albeit without taking into account all floating point pecularities.
148 When calling
\cleaninline{approxEqual
} in an
\gls{MTASK
} function, the resulting code is inlined.
150 \begin{lstClean
}[label=
{lst:example_macro
},caption=
{Example linguistic reuse in the
\gls{MTASK
} language.
}]
151 approxEqual :: (v Real) (v Real) (v Real) -> v Real | expr v
152 approxEqual x y eps = if' (x ==. y) true
159 \subsection{Data types
}
160 Most of
\gls{CLEAN
}'s fixed-size basic types are mapped on
\gls{MTASK
} types.
161 However, it can be useful to have access to compound types as well.
162 All types in
\gls{MTASK
} must have a fixed size representation on the stack so sum types are not (yet) supported.
163 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
}).
164 To be able to use types as first class citizens, constructors and field selectors are required (see
\cref{chp:first-class_datatypes
}).
165 \Cref{lst:tuple_exprs
} shows the scaffolding for supporting tuples in
\gls{MTASK
}.
166 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.
167 Examples for using tuple can be found in
\cref{sec:mtask_functions
}.
169 \begin{lstClean
}[label=
{lst:tuple_exprs
},caption=
{Tuple constructor and field selectors in
\gls{MTASK
}.
}]
171 tupl :: (v a) (v b) -> v (a, b) | type a & type b
172 first :: (v (a, b)) -> v a | type a & type b
173 second :: (v (a, b)) -> v b | type a & type b
175 tupopen f :==
\v->f (first v, second v)
178 \subsection{Functions
}\label{sec:mtask_functions
}
179 Adding functions to the language is achieved by type class to the
\gls{DSL
}.
180 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
}.
181 The
\gls{MTASK
} only allows first-order functions and does not allow partial function application.
182 This is restricted by using a multi-parameter type class where the first parameter represents the arguments and the second parameter the view.
183 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.
184 Also,
\gls{MTASK
} only supports top-level functions which is enforced by the
\cleaninline{Main
} box.
185 The definition of the type class and the instances for an example interpretation (
\cleaninline{:: Inter
}) are as follows:
187 \begin{lstClean
}[caption=
{Functions in
\gls{MTASK
}.
}]
188 class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u)))
191 instance fun () Inter where ...
192 instance fun (Inter a) Inter | type a where ...
193 instance fun (Inter a, Inter b) Inter | type a, type b where ...
194 instance fun (Inter a, Inter b, Inter c) Inter | type a, ... where ...
198 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
}.
199 \Cref{lst:function_examples
} show the factorial function, a tail-call optimised factorial function and a function with zero arguments to demonstrate the syntax.
200 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.
201 Many of the often used functions are already bundled in the
\cleaninline{mtask
} class constraint collection.
202 \cleaninline{factorialtail
} shows a manually added class constraint.
203 Definiting zero arity functions is shown in the
\cleaninline{zeroarity
} expression.
204 Finally,
\cleaninline{swapTuple
} shows an example of a tuple being swapped.
206 % VimTeX: SynIgnore on
207 \begin{lstClean
}[label=
{lst:function_examples
},caption=
{Function examples in
\gls{MTASK
}.
}]
208 factorial :: Main (v Int) | mtask v
210 fun
\fac=(
\i->if' (i <. lit
1)
212 (i *. fac (i -. lit
1)))
213 In
{main = fac (lit
5)
}
215 factorialtail :: Main (v Int) | mtask v & fun (v Int, v Int) v
217 fun
\facacc=(\(acc, i)->if' (i <. lit
1)
219 (fac (acc *. i, i -. lit
1)))
220 In fun
\fac=(
\i->facacc (lit
1, i))
221 In
{main = fac (lit
5)
}
223 zeroarity :: Main (v Int) | mtask v
225 fun
\fourtytwo=(\()->lit
42)
226 In fun
\add=(\(x, y)->x +. y)
227 In
{main = add (fourtytwo (), lit
9)
}
229 swapTuple :: Main (v (Int, Bool)) | mtask v
231 fun
\swap=(tupopen \(x, y)->tupl y x)
232 In
{main = swap (tupl true (lit
42))
}
234 % VimTeX: SynIgnore off
236 \section{Tasks and task combinators
}\label{sec:top
}
237 This section describes
\gls{MTASK
}'s task language.
238 \Gls{MTASK
}'s task language can be divided into three categories, namely
240 \item Basic tasks, in most
\gls{TOP
} systems, the basic tasks are called editors, modelling the interactivity with the user.
241 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.
242 \item Task combinators provide a way of describing the workflow.
243 They combine one or more tasks into a compound task.
244 \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.
247 As
\gls{MTASK
} is integrated with
\gls{ITASK
}, the same stability distinction is made for task values.
248 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
}.
250 \begin{lstClean
}[label=
{lst:task_type
},caption=
{Task type in
\gls{MTASK
}.
}]
251 :: MTask v a :== v (TaskValue a)
253 // From the iTask library
259 \subsection{Basic tasks
}
260 The most rudimentary basic tasks are the
\cleaninline{rtrn
} and
\cleaninline{unstable
} tasks.
261 They lift the value from the
\gls{MTASK
} expression language to the task domain either as a stable value or an unstable value.
262 There is also a special type of basic task for delaying execution.
263 The
\cleaninline{delay
} task---given a number of milliseconds---yields an unstable value while the time has not passed.
264 Once the specified time has passed, the time it overshot the planned time is yielded as a stable task value.
265 See
\cref{sec:repeat
} for an example task using
\cleaninline{delay
}.
267 \begin{lstClean
}[label=
{lst:basic_tasks
},caption=
{Function examples in
\gls{MTASK
}.
}]
268 class rtrn v :: (v t) -> MTask v t
269 class unstable v :: (v t) -> MTask v t
270 class delay v :: (v n) -> MTask v n | long v n
273 \subsubsection{Peripherals
}\label{sssec:peripherals
}
274 For every sensor or actuator, basic tasks are available that allow interaction with the specific peripheral.
275 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.
277 \Cref{lst:dht,lst:gpio
} show the type classes for
\glspl{DHT
} sensors and
\gls{GPIO
} access.
278 Other peripherals have similar interfaces, they are available in the
\cref{sec:aux_peripherals
}.
279 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.
280 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.
281 Creating such a
\cleaninline{DHT
} object is very similar to creating functions in
\gls{MTASK
} and uses
\gls{HOAS
} to make it type safe.
283 \begin{lstClean
}[label=
{lst:dht
},caption
{The
\gls{MTASK
} interface for
\glspl{DHT
} sensors.
}]
286 = DHT_DHT Pin DHTtype
288 :: DHTtype = DHT11 | DHT21 | DHT22
290 DHT :: DHTInfo ((v DHT) -> Main (v b)) -> Main (v b) | type b
291 temperature :: (v DHT) -> MTask v Real
292 humidity :: (v DHT) -> MTask v Real
294 measureTemp :: Main (MTask v Real) | mtask v & dht v
295 measureTemp = DHT (DHT_SHT (i2c
0x36))
\dht->
296 {main=temperature dht
}
299 \Gls{GPIO
} access is divided into three classes: analog, digital and pin modes.
300 For all pins and pin modes an
\gls{ADT
} is available that enumerates the pins.
301 The analog
\gls{GPIO
} pins of a microcontroller are connected to an
\gls{ADC
} that translates the voltage to an integer.
302 Analog
\gls{GPIO
} pins can be either read or written to.
303 Digital
\gls{GPIO
} pins only
report a high or a low value.
304 The type class definition is a bit more complex since analog
\gls{GPIO
} pins can be used as digital
\gls{GPIO
} pins as well.
305 Therefore, if the
\cleaninline{p
} type implements the
\cleaninline{pin
} class---i.e.\ either
\cleaninline{APin
} or
\cleaninline{DPin
}---the
\cleaninline{dio
} class can be used.
306 \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.
307 This setting can be applied using the
\cleaninline{pinMode
} class by hand or by using the
\cleaninline{declarePin
} \gls{GPIO
} pin constructor.
308 Setting the pin mode is a task that immediately finisheds and fields a stable unit value.
309 Writing to a pin is also a task that immediately finishes but yields the written value instead.
310 Reading a pin is a task that yields an unstable value---i.e.\ the value read from the actual pin.
312 \begin{lstClean
}[label=
{lst:gpio
},caption=
{The
\gls{MTASK
} interface for
\gls{GPIO
} access.
}]
313 :: APin = A0 | A1 | A2 | A3 | A4 | A5
314 :: DPin = D0 | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13
315 :: PinMode = PMInput | PMOutput | PMInputPullup
316 :: Pin = AnalogPin APin | DigitalPin DPin
317 class pin p :: p -> Pin
320 writeA :: (v APin) (v Int) -> MTask v Int
321 readA :: (v APin) -> MTask v Int
323 class dio p v | pin p where
324 writeD :: (v p) (v Bool) -> MTask v Bool
325 readD :: (v p) -> MTask v Bool | pin p
327 class pinMode v where
328 pinMode :: (v PinMode) (v p) -> MTask v () | pin p
329 declarePin :: p PinMode ((v p) -> Main (v a)) -> Main (v a) | pin p
332 \begin{lstClean
}[label=
{lst:gpio_examples
},caption=
{\Gls{GPIO
} example in
\gls{MTASK
}.
}]
333 task1 :: MTask v Int | mtask v
334 task1 = declarePin A3 PMInput
\a3->
{main=readA a3
}
336 task2 :: MTask v Int | mtask v
337 task2 = declarePin D3 PMOutput
\d3->
{main=writeD d3 true
}
340 \subsection{Task combinators
}
341 Task combinators are used to combine multiple tasks to describe workflows.
342 There are three main types of task combinators, namely:
344 \item Sequential combinators that execute tasks one after the other, possibly using the result of the left hand side.
345 \item Parallel combinators that execute tasks at the same time combining the result.
346 \item Miscellaneous combinators that change the semantics of a task---e.g.\ repeat it or delay execution.
349 \subsubsection{Sequential
}
350 Sequential task combination allows the right-hand side task to observe the left-hand side task value.
351 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{>>*.
}.
352 This combinator has a single task on the left-hand side and a list of
\emph{task continuations
} on the right-hand side.
353 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.
354 \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.
355 \cleaninline{>>|.
} is a shorthand for the sequence operation, if the left-hand side is stable, it continues with the right-hand side task.
356 The
\cleaninline{>>~.
} and
\cleaninline{>>..
} combinators are variants of the ones above that ignore the stability and continue on an unstable value as well.
358 \begin{lstClean
}[label=
{lst:mtask_sequential
},caption=
{Sequential task combinators in
\gls{MTASK
}.
}]
359 class step v | expr v where
360 (>>*.) infixl
1 :: (MTask v t)
[Step v t u
] -> MTask v u
361 (>>=.) infixl
0 :: (MTask v t) ((v t) -> MTask v u) -> MTask v u
362 (>>|.) infixl
0 :: (MTask v t) (MTask v u) -> MTask v u
363 (>>~.) infixl
0 :: (MTask v t) ((v t) -> MTask v u) -> MTask v u
364 (>>..) infixl
0 :: (MTask v t) (MTask v u) -> MTask v u
367 = IfValue ((v t) -> v Bool) ((v t) -> MTask v u)
368 | IfStable ((v t) -> v Bool) ((v t) -> MTask v u)
369 | IfUnstable ((v t) -> v Bool) ((v t) -> MTask v u)
373 The following listing shows an example of a step in action.
374 The
\cleaninline{readPinBin
} function produces an
\gls{MTASK
} task that classifies the value of an analogue pin into four bins.
375 It also shows that the nature of embedding allows the host language to be used as a macro language.
378 \begin{lstClean
}[label=
{lst:mtask_readpinbin
},caption=
{Read an analog pin and bin the value in
\gls{MTASK
}.
}]
379 readPinBin :: Int -> Main (MTask v Int) | mtask v
380 readPinBin lim = declarePin PMInput A2
\a2->
381 { main = readA a2 >>*.
382 [ IfValue (
\x->x <. lim) (
\_->rtrn (lit bin))
383 \\ lim <-
[64,
128,
192,
256]
387 \subsubsection{Parallel
}\label{sssec:combinators_parallel
}
388 The result of a parallel task combination is a compound that actually executes the tasks at the same time.
390 There are two types of parallel task combinators (see
\cref{lst:mtask_parallel
}).
391 The conjunction combinator (
\cleaninline{.&&.
}) combines the result by putting the values from both sides in a tuple.
392 The stability of the task depends on the stability of both children.
393 If both children are stable, the result is stable, otherwise the result is unstable.
394 The disjunction combinator (
\cleaninline{.\|\|.
}) combines the results by picking the leftmost, most stable task.
395 The semantics are easily described using
\gls{CLEAN
} functions shown in
\cref{lst:semantics_con,lst:semantics_dis
}.
399 \begin{subfigure
}[t
]{.5\textwidth}
400 \begin{lstClean
}[caption=
{Semantics of the\
\conjunction combinator.
},label=
{lst:semantics_con
}]
401 con :: (TaskValue a) (TaskValue b)
403 con NoValue r = NoValue
404 con l NoValue = NoValue
405 con (Value l ls) (Value r rs)
406 = Value (l, r) (ls && rs)
410 \begin{subfigure
}[t
]{.5\textwidth}
411 \begin{lstClean
}[caption=
{Semantics of the\
\disjunction combinator.
},label=
{lst:semantics_dis
}]
412 dis :: (TaskValue a) (TaskValue a)
416 dis (Value l ls) (Value r rs)
418 | otherwise = Value l ls
423 \begin{lstClean
}[label=
{lst:mtask_parallel
},caption=
{Parallel task combinators in
\gls{MTASK
}.
}]
424 class (.&&.) infixr
4 v :: (MTask v a) (MTask v b) -> MTask v (a, b)
425 class (.||.) infixr
3 v :: (MTask v a) (MTask v a) -> MTask v a
428 \Cref{lst:mtask_parallel_example
} gives an example of the parallel task combinator.
429 This program will read two pins at the same time, returning when one of the pins becomes
\arduinoinline{HIGH
}.
430 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.
432 \begin{lstClean
}[label=
{lst:mtask_parallel_example
},caption=
{Parallel task combinator example in
\gls{MTASK
}.
}]
435 declarePin D0 PMInput
\d0->
436 declarePin D1 PMInput
\d1->
437 let monitor pin = readD pin >>*.
[IfValue (
\x->x)
\x->rtrn x
]
438 In
{main = monitor d0 .||. monitor d1
}
441 \subsubsection{Repeat
}\label{sec:repeat
}
442 The
\cleaninline{rpeat
} combinator executes the child task.
443 If a stable value is observed, the task is reinstated.
444 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
}.
446 \begin{lstClean
}[label=
{lst:mtask_repeat
},caption=
{Repeat task combinators in
\gls{MTASK
}.
}]
448 rpeat :: (MTask v a) -> MTask v a
451 To demonstrate the combinator,
\cref{lst:mtask_repeat_example
} show
\cleaninline{rpeat
} in use.
452 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.
454 \begin{lstClean
}[label=
{lst:mtask_repeat_example
},caption=
{Exemplatory repeat task in
\gls{MTASK
}.
}]
455 task :: MTask v Int | mtask v
457 declarePin A1 PMInput
\a1->
458 declarePin A2 PMOutput
\a2->
459 {main = rpeat (readA a1 >>~. writeA a2 >>|. delay (lit
1000))
}
462 \subsection{\texorpdfstring{\Glsxtrlongpl{SDS
}}{Shared data sources
}}
463 \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
}).
464 Similar to peripherals (see
\cref{sssec:peripherals
}), they are constructed at the top level and are accessed through interaction tasks.
465 The
\cleaninline{getSds
} task yields the current value of the
\gls{SDS
} as an unstable value.
466 This behaviour is similar to the
\cleaninline{watch
} task in
\gls{ITASK
}.
467 Writing a new value to
\pgls{SDS
} is done using
\cleaninline{setSds
}.
468 This task yields the written value as a stable result after it is done writing.
469 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.
470 To circumvent this issue,
\cleaninline{updSds
} is created, this task atomically updates the value of the
\gls{SDS
}.
471 The
\cleaninline{updSds
} task only guarantees atomicity within
\gls{MTASK
}.
473 \begin{lstClean
}[label=
{lst:mtask_sds
},caption=
{\Glspl{SDS
} in
\gls{MTASK
}.
}]
476 sds :: ((v (Sds t)) -> In t (Main (MTask v u))) -> Main (MTask v u)
477 getSds :: (v (Sds t)) -> MTask v t
478 setSds :: (v (Sds t)) (v t) -> MTask v t
479 updSds :: (v (Sds t)) ((v t) -> v t) -> MTask v t
482 \Cref{lst:mtask_sds_examples
} shows an example using
\glspl{SDS
}.
483 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
}.
484 In the
\cleaninline{main
} expression, this function is called twice and the results are combined using the parallel or combinator (
\cleaninline{.||.
}).
485 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
}
487 \begin{lstClean
}[label=
{lst:mtask_sds_examples
},caption=
{Examples with
\glspl{SDS
} in
\gls{MTASK
}.
}]
488 task :: MTask v Int | mtask v
489 task = declarePin D3 PMInput
\d3->
490 declarePin D5 PMInput
\d5->
492 In fun
\count=(
\pin->
494 >>*
[IfValue (
\x->x) (
\_->updSds (
\x->x +. lit
1) share)
]
495 >>| delay (lit
100) // debounce
497 In
{main=count d3 .||. count d5
}
501 \Gls{MTASK
} is a rich
\gls{TOP
} language tailored for
\gls{IOT
} systems.
502 It is embedded in the pure functional language
\gls{CLEAN
} and uses an enriched lambda calculus as a host language.
503 It provides support for all common arithmetic expressions, conditionals, functions, but also several basic tasks, task combinators, peripheral support and integration with
\gls{ITASK
}.
504 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.
505 As a result, a single declarative specification can describe an entire
\gls{IOT
} system.
507 \input{subfilepostamble
}