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 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.
+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.}
\section{Class-based shallow embedding}
Let us illustrate this technique by taking the very simple language of literal values.
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 peripherals 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
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.
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)
- (x -. y <. eps)
- (y -. x <. eps)
- )
+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}
-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}.
\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.
+\todo[inline]{Uitleggen waarom je dit doet}
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?}
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.
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}
task =
declarePin D0 PMInput \d0->
declarePin D1 PMInput \d1->
- let monitor pin = readD pin >>*. [IfValue (\x->x) \x->rtrn x]
+ let monitor pin = readD pin >>*. [IfValue id rtrn]
In {main = monitor d0 .||. monitor d1}
\end{lstClean}
\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}
\subsection{Byte code compiler}
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}).
-\todo[inline]{Duidelijker maken dat het at compile time gebeurt en niet at run time.}
+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 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}.
Terms in the language are just interfaces and can be interpreted by one or more interpretations.
-\todo[inline]{Which can be used to\ldots}
-The most important interpretation of the language is the byte code compiler.
-\todo[inline]{That compiles the terms to byte code at compiletime and not run time}
+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