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.
Let us illustrate this technique by taking 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 a values, as long as it has a \cleaninline{toString} instance, from the host language to our new \gls{DSL}.
+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.
\begin{lstClean}
\end{lstClean}
Providing an evaluator is straightforward as can be seen in the following listing.
-The evaluator is just a box holding a value of the computation but it can also be something more complex such as a monadic computation.
+The evaluator is just a box holding a value of the computation, but it can also be something more complex such as a monadic computation.
\begin{lstClean}
:: Eval a = Eval a
\section{Interpretations}
This section describes all the interpretations tha the \gls{MTASK} language has.
-Not all of these interpretations are necessarily \gls{TOP} engines, i.e.\ not all of the interpretations execute the resulting tasks.
+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 so that a textual representation can be shown.
\subsection{Pretty printer}
\begin{lstClean}[caption={The entrypoint for the pretty printing interpretation.},label={lst:showmain}]
:: Show a // from the mTask pretty printing library
-showMain :: (Main (Show a)) -> [String] | type a
+showMain :: (Main (Show a)) -> [String]
\end{lstClean}
\begin{lstClean}[caption={Pretty printing interpretation example.},label={lst:showexample}]
writeD d13 state >>|. delay (lit 500) >>=. blink o Not
) In {main = blink true}
-// output:
+// output when printing:
// fun f0 a1 = writeD(D13, a1) >>= \a2.(delay 1000)
// >>| (f0 (Not a1)) in (f0 True)
\end{lstClean}
\begin{lstClean}[caption={The entrypoint for the simulation interpretation.},label={lst:simulatemain}]
:: TraceTask a // from the mTask simulator library
-simulate :: (Main (TraceTask a)) -> [String] | type a
+simulate :: (Main (TraceTask a)) -> [String]
\end{lstClean}
\begin{figure}
When using the byte code compiler interpretation in conjunction with the \gls{ITASK} integration, \gls{MTASK} 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.
-This basic language is enriched with a task language to make it \gls{TOP} (see \cref{sec:top}).
+As the language is a \gls{TOP} language, is is enriched with a task language (see \cref{sec:top}).
\section{Types}
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.
Many of these functions are usually automatically derived using generic programming but can be specialised when needed.
An even stronger restriction on types 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}.
-The class constraints for values in \gls{MTASK} are omnipresent in all functions and therefore usually omitted throughout throughout the chapters for brevity and clarity.
+The class constraints for values in \gls{MTASK} are omnipresent in all functions and therefore usually omitted for brevity and clarity.
\begin{table}[ht]
\centering
\label{tbl:mtask-c-datatypes}
\begin{tabular}{lll}
\toprule
- \cmtask{} & \ccpp{} type & \textnumero{}bits\\
+ \cmtask{} & \ccpp{} type & \textnumero{}bits\\
\midrule
- \cleaninline{Bool} & \cinline{bool} & 16\\
- \cleaninline{Char} & \cinline{char} & 16\\
- \cleaninline{Int} & \cinline{int16_t} & 16\\
- \cleaninline{Real} & \cinline{float} & 32\\
- \cleaninline{:: Long} & \cinline{int32_t} & 32\\
+ \cleaninline{Bool} & \cinline{bool} & 16\\
+ \cleaninline{Char} & \cinline{char} & 16\\
+ \cleaninline{Int} & \cinline{int16_t} & 16\\
+ \cleaninline{Real} & \cinline{float} & 32\\
+ \cleaninline{:: Long} & \cinline{int32_t} & 32\\
\cleaninline{:: T = A \| B \| C} & \cinline{enum} & 16\\
\bottomrule
\end{tabular}
\end{lstClean}
\section{Expressions}\label{sec:expressions}
-This section shows all \gls{MTASK} constructs for exppressions.
+This section shows all \gls{MTASK} constructs for expressions.
\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 numeric and boolean arithmetics; do comparisons; and conditional execution.
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.
\subsection{Data types}
Most of \gls{CLEAN}'s fixed-size basic types are mapped on \gls{MTASK} types (see \cref{tbl:mtask-c-datatypes}).
However, it is useful to have access to compound types as well.
-All types in \gls{MTASK} must have a fixed-size representation on the stack so sum types are not (yet) supported.
-While it is possible to lift any 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}).
+All types in \gls{MTASK} must have a fixed-size representation on the stack, so sum types are not (yet) supported.
+While it is possible to lift any 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}).
To be able to use types as first-class citizens, constructors, and field selectors or deconstructors are required (see \cref{chp:first-class_datatypes}).
\Cref{lst:tuple_exprs} shows the scaffolding for supporting tuples in \gls{MTASK}.
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, a deconstructor.
This is restricted by using a multi-parameter type class where the first parameter represents the arguments and the second parameter the view or 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 tuples for the arguments, partial function applications is eradicated.
-The definition of the type class and the some instances for the pretty printer are as follows:
+The definition of the type class and some instances for the pretty printer are as follows:
\begin{lstClean}[caption={Functions in \gls{MTASK}.}]
class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u)))
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}.
\Cref{lst:function_examples} show some examples of functions to demonstrate the syntax for functions.
-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.
+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.
In the \cleaninline{factorialtail} function, a tail-call optimised version of the factorial function, a manually added class constraint can be seen.
% VimTeX: SynIgnore off
\section{Tasks and task combinators}\label{sec:top}
-This section describes \gls{MTASK}'s task language.
-Tasks can be seen as trees that are the result of evaluating expressions.
-After evaluating an expression, the resulting task is executed.
-\todo[inline]{iets zeggen over values en dat hier ook een handwavy semantiek is.}
-The execution semantics of tasks is explained in more detail in \cref{chp:implementation}.
+This section describes the task language of \gls{MTASK}.
+\Gls{TOP} languages are languages enriched with tasks.
+Tasks represent abstract pieces of work and can be combined using combinators.
+Creating tasks is done by evaluating expressions and this is called a task tree, a run time representation of a task.
+After evaluation, the resulting task tree is \emph{rewritten}, i.e.\ they are continuously given a small slice of execution time after which a task value is yielded.
+This task value is observable by other tasks and can be acted upon.
+\todo{dui\-de\-lijk ge\-noeg?}
+
+The implementation in the \gls{MTASK} \gls{RTS} for task execution is shown in \cref{chp:implementation}.
+The following sections show the definition of the functions for creating tasks.
+They also show the semantics of tasks, their observable value in relation to the work that the task represents.
The task language of \gls{MTASK} is divided into three categories, namely
+
\begin{description}
\item [Basic tasks] are the leaves in the task trees.
In most \gls{TOP} systems, the basic tasks are called editors, modelling the interactivity with the user.
\end{lstClean}
\subsubsection{Peripherals}\label{sssec:peripherals}
-For every sensor or actuator, basic tasks are available that allow interaction with the specific peripheral.
+In order for the edge devices to interact with their 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 all peripherals connected.
\Cref{lst:dht} shows the type classes for \glspl{DHT} sensors.
{main=temperature dht}
\end{lstClean}
-\todo[inline]{Uitleggen wat GPIO is}
+An example of a built-in peripheral is the \gls{GPIO} system.
+This array of digital and analogue pins is controlled through software.
\Gls{GPIO} access is divided into three classes: analogue \gls{IO}, digital \gls{IO} and pin modes configuration (see \cref{lst:gpio}).
For all pins and pin modes an \gls{ADT} is available that enumerates the pins.
The analogue \gls{GPIO} pins of a microcontroller are connected to an \gls{ADC} that translates the measured voltage to an integer.
Digital \gls{GPIO} pins of a microcontroller report either a high or a low value.
-Both analogue and digital \gls{GPIO} pins can be read or written to but it is advised to set the pin mode accordingly.
+Both analogue and digital \gls{GPIO} pins can be read or written to, but it is advised to set the pin mode accordingly.
The \cleaninline{pin} type class allows functions to be overloaded in either the analogue or digital pins, e.g.\ analogue pins can be considered as digital pins as well.
For digital \gls{GPIO} interaction, the \cleaninline{dio} type class is used.
\subsection{Task combinators}
Task combinators are used to combine multiple tasks to describe workflows.
-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.
+The \gls{MTASK} language has a set of simpler combinators from which more complicated workflow can be derived.
There are three main types of task combinators, namely:
\begin{enumerate}
- \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---e.g.\ repeat it or delay execution.
+ \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.
\end{enumerate}
\subsubsection{Sequential}
Sequential task combination allows the right-hand side expression to \emph{observe} the left-hand side task value.
-All sequential task combinators are expressed in the \cleaninline{step} class and can be---and are by default---derived from the Swiss army knife step combinator \cleaninline{>>*.}.
+All sequential task combinators are expressed in the \cleaninline{step} class and are by default derived from the Swiss Army knife step combinator \cleaninline{>>*.}.
This combinator has a single task on the left-hand side and a list of \emph{task continuations} on the right-hand side.
The list of task continuations is checked during evaluation of the left-hand side and if one of the predicates matches, the task continues with the result of this combination.
Several shorthand combinators are derived from the step combinator.
The conjunction combinator (\cleaninline{.&&.}) combines the result by putting the values from both sides in a tuple.
The stability of the task depends on the stability of both children.
If both children are stable, the result is stable, otherwise the result is unstable.
-The disjunction combinator (\cleaninline{.\|\|.}) combines the results by picking the leftmost, stablest task.
+The disjunction combinator (\cleaninline{.\|\|.}) combines the results by picking the leftmost, most stable task.
The semantics are most easily described using the \gls{CLEAN} functions shown in \cref{lst:semantics_con,lst:semantics_dis}.
\begin{figure}[ht]
\end{lstClean}
\subsection{\texorpdfstring{\Glsxtrlongpl{SDS}}{Shared data sources}}
-\todo[inline]{Explain \glspl{SDS} shortly.}
+Tasks not always communicate using their observable 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 this data with other tasks in the system.
\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}).
-Similar to peripherals (see \cref{sssec:peripherals}), they are constructed at the top level and are accessed through interaction tasks.
+There are no combinators or user-defined \gls{SDS} types in \gls{MTASK}.
+Similar to peripherals and functions, \glspl{SDS} are constructed at the top level with the \cleaninline{sds} function.
+They are accessed through interaction tasks.
The \cleaninline{getSds} task yields the current value of the \gls{SDS} as an unstable value.
This behaviour is similar to the \cleaninline{watch} task in \gls{ITASK}.
Writing a new value to \pgls{SDS} is done using \cleaninline{setSds}.
repositories / phd-thesis.git / blobdiff