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.\todo{by whom? would be good here to be more explicit to make it clear at this point whether that's part of the contribution}
+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.
-\todo{show how this relates to the general embedding discussion previously}
+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.
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}]
(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 peculiarities.
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.
-The \cleaninline{factorial} functions shows a recursive version of the factorial function.
+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.
\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}.
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 exact time the task overshot the target time is yielded as a stable task value.\todo{unclear?}
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}.}]
\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 embedded \gls{DSL} in the pure functional host language \gls{CLEAN}.
+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.
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.
+\todo{would be nice to see an example of this}
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / blobdiff