\input{subfilepreamble}
-\setcounter{chapter}{3}
+\setcounter{chapter}{4}
\begin{document}
\input{subfileprefix}
-\chapter{The \texorpdfstring{\gls{MTASK}}{mTask} language}%\texorpdfstring{\glsxtrshort{DSL}}{DSL}}%
+\chapter{The mTask language}%
\label{chp:mtask_dsl}
\begin{chapterabstract}
This chapter introduces the \gls{TOP} language \gls{MTASK} by:
This means that the language interface, i.e.\ the language constructs, are a collection of type classes.
Interpretations of this interface are data types implementing these classes.
Due to the nature of this embedding technique, it is possible to have multiple interpretations for programs written in the \gls{MTASK} language.
-Furthermore, this particular type of embedding has the property that it is extensible both in language constructs and in intepretations.
-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.
+Furthermore, this particular type of embedding has the property that it is extensible both in language constructs and in interpretations.
+Adding a language construct is as simple as adding a type class.
+Adding an interpretation is done by creating a new data type and providing implementations for the various type classes.
+
+In order to reduce the hardware requirements for devices running \gls{MTASK} programs, several measures have been taken that are reflected in the language design.
+Programs in \gls{MTASK} are written in the \gls{MTASK} \gls{DSL}, separating them from the host \gls{ITASK} program.
+This allows the tasks to be constructed at compile time in order to tailor-make them for the specific work requirements.
+Furthermore, the \gls{MTASK} language is restricted: there are no recursive data structures, no higher-order functions, strict evaluation, and functions and objects can only be declared at the top level.
\section{Class-based shallow embedding}
-Let us illustrate this technique by taking the very simple language of literal values.
+The \gls{MTASK} language is implemented as a class-based shallow, also known as tagless-final, embedded \gls{DSL} (see also \cref{sec:tagless-final}).
+In order to demonstrate the technique, it is first illustrated by showing the very simple language of literal values.
This language interface can be described using a single type constructor class with a single function \cleaninline{lit}.
This function is for lifting values, when it has a \cleaninline{toString} instance, from the host language to our new \gls{DSL}.
The type variable \cleaninline{v} of the type class represents the view on the language, the interpretation.
\section{Types}
The \gls{MTASK} language is a tagless-final \gls{EDSL} as well.
-As it is shallowly embedded, the types of the terms in the language can be constrained by type classes.
+As it is shallow embedded, the types of the terms in the language can be constrained by type classes.
Types in the \gls{MTASK} language are expressed as types in the host language, to make the language type safe.
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 added to the \gls{DSL} functions.
\Cref{tbl:mtask-c-datatypes} shows the mapping from \gls{CLEAN} types to \ccpp{} types.
-The most used class constraint is the \cleaninline{type} class collection containing functions for serialization, printing, \gls{ITASK} constraints, \etc\ \citep[\citesection{6.9}]{plasmeijer_clean_2021}.
+The most used class constraint is the \cleaninline{type} class collection containing functions for serialisation, printing, \gls{ITASK} constraints, \etc\ \citep[\citesection{6.9}]{plasmeijer_clean_2021}.
Most of these functions are automatically derivable using generic programming but can be specialised when needed.
An even stronger restriction is defined for types that have a stack representation.
This \cleaninline{basicType} class has instances for many \gls{CLEAN} basic types such as \cleaninline{Int}, \cleaninline{Real} and \cleaninline{Bool}.
\end{tabular}
\end{table}
-\footnote{In \gls{ARDUINO} \ccpp{} this usually equals a \cinline{long}.}
+\footnotetext{In \gls{ARDUINO} \ccpp{} this usually equals a \cinline{long}.}
\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.
\begin{lstClean}[caption={Classes and class collections for the \gls{MTASK} language.},label={lst:constraints}]
The \gls{MTASK} language interface consists of a core collection of type classes bundled in the type class \cleaninline{class mtask} (see \cref{lst:collection}).
Every interpretation of \gls{MTASK} terms implements the type classes in the \cleaninline{mtask} class collection.
-Optional \gls{MTASK} constructs such as perpipherals or lowered \gls{ITASK} \glspl{SDS} are not included in this class collection because not all devices or interpretations support this.
+%Optional \gls{MTASK} constructs such as peripherals or lowered \gls{ITASK} \glspl{SDS} are not included in this class collection because not all devices or interpretations support this.
\begin{lstClean}[caption={Class collection for the \gls{MTASK} language.},label={lst:collection}]
class mtask v | expr, ..., int, real, long v
This is enforced by the \cleaninline{Main} type.
Most top level definitions are defined using \gls{HOAS}.
To make their syntax friendlier, the \cleaninline{In} type---an infix tuple---is used to combine these top level definitions.
-To illustrate the structure of a \gls{MTASK} programs, \cref{lst:mtask_types} shows a skeleton of a program.
+To illustrate the structure of \gls{MTASK} programs, \cref{lst:mtask_types} shows a skeleton of a program.
% VimTeX: SynIgnore on
\begin{lstClean}[caption={Auxiliary types and example task in the \gls{MTASK} language.},label={lst:mtask_types}]
:: Main a = { main :: a }
:: In a b = (In) infix 0 a b
-someTask :: MTask v Int | mtask v & liftsds v & sensor1 v & ...
+someTask :: MTask v Int | mtask v & lowerSds v & sensor1 v & ...
someTask =
sensor1 config1 \sns1->
sensor2 config2 \sns2->
- sds \s1 = initialValue
- In liftsds \s2 = someiTaskSDS
- In fun \fun1= ( \(a0, a1)->... )
- In fun \fun2= ( \a->... )
+ sds \s1 = initialValue
+ In lowerSds \s2 = someiTaskSDS
+ In fun \fun1 = ( \(a0, a1)->... )
+ In fun \fun2 = ( \a->... )
In { main = mainexpr }
\end{lstClean}
% VimTeX: SynIgnore off
In \gls{CLEAN}, all free variables in a type are implicitly universally quantified.
In order to use the \gls{MTASK} expressions with multiple interpretations, rank-2 polymorphism is required \citep{odersky_putting_1996}.
\Cref{lst:rank2_mtask} shows an example of a function that simulates an \gls{MTASK} expression while showing the pretty printed representation in parallel.
-Providing a type for the \cleaninline{simulateAndPrint} function is mandatory as the compiler cannot infer the type of rank-2 polymorphic functions\citep[\citesection{3.7.4}]{plasmeijer_clean_2021}.
+Providing a type for the \cleaninline{simulateAndPrint} function is mandatory as the compiler cannot infer the type of rank-2 polymorphic functions \citep[\citesection{3.7.4}]{plasmeijer_clean_2021}.
\begin{lstClean}[label={lst:rank2_mtask},caption={Rank-2 polymorphism to allow multiple interpretations.}]
simulateAndPrint :: (A.v: Main (MTask v a) | mtask v) -> Task a | type a
If :: (v Bool) (v t) (v t) -> v t | type t
\end{lstClean}
-Conversion to-and-fro data types is available through the overloaded functions \cleaninline{int}, \cleaninline{long} and \cleaninline{real}.
+Conversion to and fro data types is available through the overloaded functions \cleaninline{int}, \cleaninline{long} and \cleaninline{real}.
These functions convert the argument to the respective type similar to casting in \gls{C}.
For most interpretations, there are instances of these classes for all numeric types.
\Cref{lst:example_exprs} shows some examples of expressions in the \gls{MTASK} language.
Since they are only expressions, there is no need for a \cleaninline{Main}.
\cleaninline{e0} defines the literal \num{42}, \cleaninline{e1} calculates the literal \num{42.0} using real numbers and uses a type conversion.
-\cleaninline{e2} compares \cleaninline{e0} and \cleaninline{e1} as integers and if they are equal it returns $\frac{\text{\cleaninline{e2}}}{2}$ and \cleaninline{e0} otherwise.
+\cleaninline{e2} compares \cleaninline{e0} and \cleaninline{e1} as integers and if they are equal it returns $\nicefrac{\text{\cleaninline{e2}}}{2}$ and \cleaninline{e0} otherwise.
\begin{lstClean}[label={lst:example_exprs},caption={Example \gls{MTASK} expressions.}]
e0 :: v Int | expr v
(int e1 /. lit 2) e0
\end{lstClean}
-The \gls{MTASK} language is shallowly embedded in \gls{CLEAN} and the terms are constructed and hence compiled at run time.
+The \gls{MTASK} language is shallow embedded in \gls{CLEAN} and the terms are constructed and hence compiled at run time.
This means that \gls{MTASK} programs can also be tailor-made at run time using \gls{CLEAN} functions, maximising the linguistic reuse \citep{krishnamurthi_linguistic_2001}.
The \cleaninline{approxEqual} function in \cref{lst:example_macro} is an example of this.
-It performs a simple approximate equality---admittedly not taking into account all floating point pecularities.
+It performs a simple approximate equality---admittedly not taking into account all floating point peculiarities.
When calling \cleaninline{approxEqual} in an \gls{MTASK} expression, the resulting code is inlined.
-\begin{lstClean}[label={lst:example_macro},caption={Approximate equality as an example of linguistic reuse in \gls{MTASK}.}]
-approxEqual :: (v Real) (v Real) (v Real) -> v Real | expr v
-approxEqual x y eps = If (x ==. y) true
- ( If (x >. y)
+\begin{lstClean}[label={lst:example_macro},caption={Approximate equality in \gls{MTASK}.}]
+approxEqual :: (v Real) (v Real) (v Real) -> v Bool | expr v
+approxEqual x y eps = x ==. y
+ |. If (x >. y)
(x -. y <. eps)
(y -. x <. eps)
- )
\end{lstClean}
\subsection{Data types}
\end{lstClean}
\subsection{Functions}\label{sec:mtask_functions}
-Adding functions to the language is achieved by one type class to the \gls{DSL}.
-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}.
-The \gls{MTASK} language only allows first-order functions and no partial function application.
-To restrict this, a multi-paramater type class is used instead of a type class with one type variable.
+Adding functions to the language is achieved by one type class in the \gls{MTASK} \gls{DSL}.
+By using \gls{HOAS}, both the function definitions and the calls to the functions are controlled by the \gls{DSL} \citep{pfenning_higher-order_1988,chlipala_parametric_2008}.
+The \gls{MTASK} language enforces all functions to be first-order and forbids partial function application in order to reduce memory use and code size.
+These restrictions are enforced by using a multi-parameter type class with two parameters instead of a type class with one type variable.
The first parameter represents the shape of the arguments, the second parameter the interpretation.
An instance is provided for each function arity instead of providing an instance for all possible arities to enforce that all functions are first order.
-By using argument tuples to represent the arity of the function, partial function applications are eradicated.
-The definition of the type class and some instances for the pretty printer are as follows:
+By using argument tuples to represent the arity of the function, it is not possible to create partial function applications.
+The definition of the type class and some instances for the pretty printer are shown in \cref{lst:fun_mtask}.
-\begin{lstClean}[caption={Functions in \gls{MTASK}.}]
+\begin{lstClean}[float=,caption={Functions in \gls{MTASK}.},label={lst:fun_mtask}]
class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u)))
-> Main (MTask v u)
...
\end{lstClean}
-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}.
+Deriving how to define and use functions from the type is quite a challenge even though the resulting syntax is made easier using the infix type \cleaninline{In}.
+Splitting out the function definition for each single arity means that for every function arity and combination of arguments, a separate class constraint is required.
+Many of the often used functions signatures are in the \cleaninline{mtask} class constraint collection.
\Cref{lst:function_examples} show some examples of functions to illustrate the syntax.
-Splitting out the function definition for each single arity means that for every function arity and combination of arguments, a separate class constraint must be created.
-Many of the often used functions are already bundled in the \cleaninline{mtask} class constraint collection.
-The \cleaninline{factorial} functions shows a recursive version of the factorial function.
-The \cleaninline{factorialtail} function is a tail-call optimised version of the factorial function.
-It contains a manually added class constraint.
-Zero-arity functions are always called with unit as an argument.
-An illustration of this is seen in the \cleaninline{zeroarity} expression.
-Finally, \cleaninline{swapTuple} shows an example of a tuple being swapped.
+The \cleaninline{factorial} function shows a recursive version of the factorial function.
+The \cleaninline{factorialtail} function is a tail-call optimised version of the above.
+It also illustrates a manually added class constraint, as they are required when functions are used that have signatures not present in the \cleaninline{mtask} class collection.
+Zero-arity functions are always called with unit as an argument, which is shown in the \cleaninline{zeroarity} function.
+Finally, the \cleaninline{swapTuple} function shows an example of a tuple being swapped using the \cleaninline{tupopen} macro (see \cref{lst:tuple_exprs}).
% VimTeX: SynIgnore on
\begin{lstClean}[label={lst:function_examples},caption={Examples of various functions in \gls{MTASK}.}]
factorial :: Main (v Int) | mtask v
factorial =
- fun \fac=(\i->If (i <. lit 1)
+ fun \fac = (\i->If (i <. lit 1)
(lit 1)
(i *. fac (i -. lit 1)))
In {main = fac (lit 5) }
factorialtail :: Main (v Int) | mtask v & fun (v Int, v Int) v
factorialtail =
- fun \facacc=(\(acc, i)->If (i <. lit 1)
+ fun \facacc = (\(acc, i)->If (i <. lit 1)
acc
(fac (acc *. i, i -. lit 1)))
- In fun \fac=(\i->facacc (lit 1, i))
+ In fun \fac = (\i->facacc (lit 1, i))
In {main = fac (lit 5) }
zeroarity :: Main (v Int) | mtask v
zeroarity =
- fun \fourtytwo=(\()->lit 42)
- In fun \add=(\(x, y)->x +. y)
+ fun \fourtytwo = (\()->lit 42)
+ In fun \add = (\(x, y)->x +. y)
In {main = add (fourtytwo (), lit 9)}
-
+ [+\pagebreak+]
swapTuple :: Main (v (Int, Bool)) | mtask v
swapTuple =
- fun \swap=(tupopen \(x, y)->tupl y x)
+ fun \swap = (tupopen \(x, y)->tupl y x)
In {main = swap (tupl true (lit 42)) }
\end{lstClean}
% VimTeX: SynIgnore off
Tasks represent abstract pieces of work and can be combined using combinators.
Creating tasks is done by evaluating expressions.
The result of an evaluated task expression is called a task tree, a run time representation of a task.
-In order to evaluate a task, the resulting task tree is \emph{rewritten}, i.e.\ similar to rewrite systems, they perform a bit of work, step by step.
+In order to evaluate a task, the resulting task tree is \emph{rewritten} using small-step reduction, i.e.\ similar to rewrite systems, they perform a bit of work, step by step.
With each step, a task value is yielded that is observable by other tasks and can be acted upon.
The implementation in the \gls{MTASK} \gls{RTS} for task execution is shown in \cref{chp:implementation}.
\item [Task combinators] provide a way of describing the workflow or collaboration.
They combine one or more tasks into a compound task.
\item [\Glspl{SDS}] are typed references to shared memory in \gls{MTASK}.
- The data is available for tasks using many-to-many communication but only from within the task language to ensure atomicity.
+ The data is available for tasks using many-to-many communication.
+ Reading, writing and updating \glspl{SDS} is an atomic operation on the task level.
\end{description}
As \gls{MTASK} is integrated with \gls{ITASK}, a stability distinction is made for task values just as in \gls{ITASK}.
\subsection{Basic tasks}
The \gls{MTASK} language contains interactive and non-interactive basic tasks.
+As \gls{MTASK} is integrated in \gls{ITASK}, the same notion of stability is applied to the task values.
+Task values have either \emph{no value}, or are \emph{unstable} or \emph{stable} (see \cref{fig:taskvalue}).
+Once a task yields a stable value, it does not change anymore.
The most rudimentary non-interactive basic tasks in the task language of \gls{MTASK} are \cleaninline{rtrn} and \cleaninline{unstable}.
They lift the value from the \gls{MTASK} expression language to the task domain either as a stable or unstable value.
There is also a special type of basic task for delaying execution.
The \cleaninline{delay} task---parametrised by a number of milliseconds---yields an unstable value while the time has not passed.
-Once the specified time has passed, the time it overshot the planned time is yielded as a stable task value.
+Once the specified time has passed, the time the task overshot the target time is yielded as a stable task value.
See \cref{sec:repeat} for an example task using \cleaninline{delay}.
\begin{lstClean}[label={lst:basic_tasks},caption={Non-interactive basic tasks in \gls{MTASK}.}]
In order for the edge device to interact with the environment, peripherals such as sensors and actuators are employed.
Some peripherals are available on the microcontroller package, others are connected with wires using protocols such as \gls{I2C}.
For every supported sensor or actuator, basic tasks are available that allow interaction with the specific peripheral.
-The type classes for these tasks are not included in the \cleaninline{mtask} class collection as not all devices nor all language interpretations support every peripherals connected.
+The type classes for these tasks are not included in the \cleaninline{mtask} class collection as not all devices nor all language interpretations support every peripheral connected.
An example of a built-in peripheral is the \gls{GPIO} system.
This array of digital and analogue pins is controlled through software.
Analogue \gls{GPIO} tasks are bundled in the \cleaninline{aio} type class.
\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.
This setting can be set using the \cleaninline{pinMode} class by hand or by using the \cleaninline{declarePin} \gls{GPIO} pin constructor to declare it at the top level.
-Setting the pin mode is a task that immediately finisheds and yields a stable unit value.
+Setting the pin mode is a task that immediately finishes and yields a stable unit value.
Writing to a pin is also a task that immediately finishes, but yields the written value.
Reading a pin is a task that yields an unstable value---i.e.\ the value read from the actual pin.
For the \gls{DHT} sensor there are two basic tasks, \cleaninline{temperature} and \cleaninline{humidity}, that produce a task that yields the observed temperature in \unit{\celcius} or the relative humidity as an unstable value.
Other peripherals have similar interfaces, they are available in \cref{sec:aux_peripherals}.
-\begin{lstClean}[label={lst:dht},caption={The \gls{MTASK} interface for \glspl{DHT} sensors.}]
+\begin{lstClean}[float=,label={lst:dht},caption={The \gls{MTASK} interface for \glspl{DHT} sensors.}]
:: DHT //abstract
:: DHTInfo
= DHT_DHT Pin DHTtype
\begin{itemize}
\item sequential combinators that execute tasks one after the other, possibly using the result of the left-hand side;
\item parallel combinators that execute tasks at the same time, combining the result;
- \item miscellaneous combinators that change the semantics of a task---for example a combinator that repeats the child task.
+ \item and miscellaneous combinators that change the semantics of a task---for example a combinator that repeats the child task.
\end{itemize}
\subsubsection{Sequential}
All sequential task combinators are defined in the \cleaninline{step} class and are by default defined in terms of the Swiss Army knife step combinator (\cleaninline{>>*.}, \cref{lst:mtask_sequential}).
This combinator has a single task on the left-hand side and a list of \emph{task continuations} on the right-hand side.
Every rewrite step, the list of task continuations are tested on the task value.
-If one of the predicates matches, the task continues with the result of this continuations.
+If one of the predicates matches, the task continues with the result of these continuations.
Several shorthand combinators are derived from the step combinator.
-\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.
-\cleaninline{>>\|.} is a shorthand for the sequence operation, if the left-hand side is stable, it continues with the right-hand side task.
+The \cleaninline{>>=.} combinator 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.
+The \cleaninline{>>\|.} combinator is a shorthand for the sequence operation, if the left-hand side is stable, it continues with the right-hand side task.
The \cleaninline{>>~.} and \cleaninline{>>..} combinators are variants of the ones above that ignore the stability and continue on an unstable value as well.
\begin{lstClean}[label={lst:mtask_sequential},caption={Sequential task combinators in \gls{MTASK}.}]
| Always (MTask v u)
\end{lstClean}
-The following listing shows an example of a step in action.
+\Cref{lst:mtask_readpinbin} shows an example task containing a step.
The \cleaninline{readPinBin} function produces an \gls{MTASK} task that classifies the value of an analogue pin into four bins.
It also shows that the nature of embedding allows the host language to be used as a macro language.
The disjunction combinator (\cleaninline{.\|\|.}) combines the results by picking the leftmost, most stable task.
The semantics of both parallel combinators are most easily described using the \gls{CLEAN} functions shown in \cref{lst:semantics_con,lst:semantics_dis}.
-\begin{figure}[ht]
+\begin{figure}
\centering
\begin{subfigure}[t]{.5\textwidth}
\begin{lstClean}[caption={Semantics of the\\conjunction combinator.},label={lst:semantics_con}]
dis NoValue r = r
dis l NoValue = l
dis (Value l ls) (Value r rs)
- | rs = Value r True
+ | rs && not ls = Value r rs
| otherwise = Value l ls
\end{lstClean}
\end{subfigure}
This task read two pins at the same time, returning when one of the pins becomes high.
If the combinator was the \cleaninline{.&&.}, the type would be \cleaninline{MTask v (Bool, Bool)} and the task would only return when both pins are high but not necessarily at the same time.
-\begin{lstClean}[label={lst:mtask_parallel_example},caption={Parallel task combinator example in \gls{MTASK}.}]
+\begin{lstClean}[float=,label={lst:mtask_parallel_example},caption={Parallel task combinator example in \gls{MTASK}.}]
task :: MTask v Bool
task =
declarePin D0 PMInput \d0->
declarePin D1 PMInput \d1->
- let monitor pin = readD pin >>*. [IfValue (\x->x) \x->rtrn x]
+ fun \monitor = (\pin->readD pin >>*. [IfValue id rtrn])
In {main = monitor d0 .||. monitor d1}
\end{lstClean}
{main = rpeat (readA a1 >>~. writeA a2 >>|. delay (lit 1000))}
\end{lstClean}
-\subsection{\texorpdfstring{\Glsxtrlongpl{SDS}}{Shared data sources}}
+\subsection{Shared data sources}
For some collaborations it is cumbersome to only communicate data using task values.
\Glspl{SDS} are a safe abstraction over any data that fill this gap.
It allows tasks to safely and atomically read, write and update data stores in order to share data with other tasks.
\begin{lstClean}[label={lst:mtask_sds_examples},caption={Examples with \glspl{SDS} in \gls{MTASK}.}]
task :: MTask v Int | mtask v
-task = declarePin D3 PMInput \d3->
+task =
+ declarePin D3 PMInput \d3->
declarePin D5 PMInput \d5->
sds \share=0
In fun \count=(\pin->
readD pin
- >>* [IfValue (\x->x) (\_->updSds (\x->x +. lit 1) share)]
+ >>* [IfValue id (\_->updSds (\x->x +. lit 1) share)]
>>| delay (lit 100) // debounce
>>| count pin)
In {main=count d3 .||. count d5}
\end{lstClean}
\section{Interpretations}
-This section describes all the interpretations that the \gls{MTASK} language has.
-Not all of these interpretations are necessarily \gls{TOP} engines, i.e.\ not all the interpretations execute the resulting tasks.
-Some may perform an analysis over the program or typeset the program.
+The nature of the \gls{MTASK} \gls{DSL} embedding allows for multiple interpretations of the terms in the language.
+The \gls{MTASK} language has interpretations to pretty print, simulate, and generate byte code for terms in the language.
+There are many other interpretations possible such as static analyses or optimisation.
+Not all these interpretations are necessarily \gls{TOP} engines, i.e.\ not all the interpretations execute the resulting tasks.
\subsection{Pretty printer}
The pretty printer interpretation converts an \gls{MTASK} term to a string representation.
It runs the pretty printer and returns a list of strings containing the pretty printed result.
The pretty printing function does the best it can but obviously cannot reproduce layout, curried functions, and variable names.
This shortcoming is illustrated by printing a blink task that contains a function and currying in \cref{lst:showexample}.
+The output of this action would be \cleaninline{fun f0 a1 = writeD(D13, a1) >>= \\a2.(delay 1000) >>\| (f0 (Not a1)) in (f0 True)}
-\begin{lstClean}[caption={The entrypoint for the pretty printing interpretation.},label={lst:showmain}]
+\begin{lstClean}[caption={The entry point for the pretty printing interpretation.},label={lst:showmain}]
:: Show a // from the mTask pretty printing library
showMain :: (Main (Show a)) -> [String]
\end{lstClean}
fun \blink=(\state->
writeD d13 state >>|. delay (lit 500) >>=. blink o Not
) In {main = blink true}
-
-// output when printing:
-// fun f0 a1 = writeD(D13, a1) >>= \a2.(delay 1000)
-// >>| (f0 (Not a1)) in (f0 True)
\end{lstClean}
\subsection{Simulator}
-The simulator converts the expression to a ready-for-work \gls{ITASK} simulation.
-There is one entrypoint for this interpretation (see \cref{lst:simulatemain}).
+In a real microprocessor, it is hard to observe the state and to control the sensors in such a way that the behaviour of interest can be observed.
+The simulator converts the expression to a ready-for-work \gls{ITASK} simulation to bridge this gap.
+There is one entry point for this interpretation (see \cref{lst:simulatemain}).
The task resulting from the \cleaninline{simulate} function presents the user with an interactive simulation environment (see \cref{fig:sim}).
The simulation allows the user to (partially) execute tasks, control the simulated peripherals, inspect the internal state of the tasks, and interact with \glspl{SDS}.
-\begin{lstClean}[caption={The entrypoint for the simulation interpretation.},label={lst:simulatemain}]
+\begin{lstClean}[caption={The entry point for the simulation interpretation.},label={lst:simulatemain}]
:: TraceTask a // from the mTask simulator library
simulate :: (Main (TraceTask a)) -> [String]
\end{lstClean}
\end{figure}
\subsection{Byte code compiler}
-The main interpretation of the \gls{MTASK} system is the byte code compiler (\cleaninline{:: BCInterpret}).
+The main interpretation of the \gls{MTASK} system is the byte code compiler (\cleaninline{:: BCInterpret a}).
+This interpretation compiles the \gls{MTASK} term at run time to byte code.
With it, and a handful of integration functions, \gls{MTASK} tasks can be executed on microcontrollers and integrated in \gls{ITASK} as if they were regular \gls{ITASK} tasks.
Furthermore, with a special language construct, \glspl{SDS} can be shared between \gls{MTASK} and \gls{ITASK} programs as well.
The integration with \gls{ITASK} is explained thoroughly later in \cref{chp:integration_with_itask}.
The \gls{MTASK} language together with \gls{ITASK} is a heterogeneous \gls{DSL}.
I.e.\ some components---for example the \gls{RTS} on the microcontroller that executes the tasks---is largely unaware of the other components in the system, and it is executed on a completely different architecture.
-The \gls{MTASK} language is based on a simply-typed $\lambda$-calculus with support for some basic types, arithmetic operations, and function definitions.
-As the language is a \gls{TOP} language, it is also enriched with a task language (see \cref{sec:top}).
+The \gls{MTASK} language is a \gls{TOP} language with basic tasks tailored for \gls{IOT} edge devices (see \cref{sec:top}).
+It uses expressions based a simply-typed $\lambda$-calculus with support for some basic types, arithmetic operations, and function definitions.
\section{Conclusion}
+This chapter gave an overview of the complete \gls{MTASK} \gls{DSL}.
The \gls{MTASK} language is a rich \gls{TOP} language tailored for \gls{IOT} edge devices.
-The language is implemented as a class-based shallowly \gls{EDSL} in the pure functional host language \gls{CLEAN}.
-The language is an enriched lambda calculus as a host language.
-It provides language constructs for arithmetic expressions, conditionals, functions, but also non-interactive basic tasks, task combinators, peripheral support, and integration with \gls{ITASK}.
+The language is implemented as a class-based shallow embedded \gls{DSL} in the pure functional host language \gls{CLEAN}.
+The language uses an enriched lambda calculus as a host language, providing additional language constructs for arithmetic expressions, conditionals, functions, but also non-interactive basic tasks, task combinators, peripheral support, and integration with \gls{ITASK}.
Terms in the language are just interfaces and can be interpreted by one or more interpretations.
-The most important interpretation of the language is the byte code compiler.
+When using the byte code compiler, terms in the \gls{MTASK} language are type checked at compile time but are constructed and compiled at run time.
+This facilitates tailor-making tasks for the current work requirements.
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / blobdiff