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.
-\todo[inline]{Is dit niet de plek om uit te leggen welke restricties we aan mTask opleggen om het op een edge device te kunnen draaien?
- 1 onderscheid tussen mTask en de rest van het programma
- 2 mTask uit kunnen voeren zonder heap gebruik anders dan de task expressie. Dus:
- a geen recursieve data types
- b geen hogere orde functies
- c strict evaluation
- d functies en objecten alleen op topniveau
-Nu lijkt het af en toe dat mTask onnodig primitief is, terwijl we het ook algemener hadden kunnen doen.}
+In order to reduce the hardware requirements for devices running \gls{MTASK} programs, several measures have been taken.
+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.
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.
-\todo[inline]{Uitleggen waarom je dit doet}
+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.
An illustration of this is seen in the \cleaninline{zeroarity} expression.
Finally, \cleaninline{swapTuple} shows an example of a tuple being swapped.
\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 observable task value (see \cref{fig:taskvalue}).
-\todo[inline]{Stability beter uitleggen?}
+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.
\end{lstClean}
\section{Interpretations}
-\todo[inline]{Iets meer uitleg over waarom dit zo handig is}
-This section describes all the interpretations that the \gls{MTASK} language has to offer.
+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.
-Some may perform an analysis over the program or typeset the program.
\subsection{Pretty printer}
The pretty printer interpretation converts an \gls{MTASK} term to a string representation.
\end{lstClean}
\subsection{Simulator}
-The simulator converts the expression to a ready-for-work \gls{ITASK} simulation.
+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}.
repositories / phd-thesis.git / blobdiff