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.
+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 and adding an interpretation is done by creating a new data type and providing implementations for the various type classes.
\section{Class-based shallow embedding}
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}.
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
The \gls{MTASK} language is shallowly 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}.}]
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.
+To restrict this, a multi-parameter type class is used 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.
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.
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.
\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.
+Not all 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.
\subsection{Pretty printer}
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}.
-\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}
\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}).
+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}
repositories / phd-thesis.git / blobdiff