\input{subfilepreamble}
+\setcounter{chapter}{1}
+
\begin{document}
\input{subfileprefix}
\chapter{First-class data types in shallow \texorpdfstring{embedded domain-specific languages}{\glsxtrlongpl{EDSL}} using metaprogramming}%
\label{chp:first-class_datatypes}%
+%\chaptermark{First-class data types in shallow eDSLs using metaprogramming}
\begin{chapterabstract}
\Gls{FP} languages are excellent for hosting \glspl{EDSL} because of their rich type systems, minimal syntax, and referential transparency.
However, data types defined in the host language are not automatically available in the embedded language.
\begin{lstHaskell}[frame=]
<$> :: (a -> b) -> f a -> f b
<*> :: f (a -> b) -> f a -> f b
-infixl 4 <$>, <*>
- \end{lstHaskell}
+infixl 4 <$>, <*>\end{lstHaskell}
\end{lrbox}
\footnotetext{\usebox{\LstBox}}
infix 1 :-
\end{lstHaskell}
-Using the \haskellinline{Function} type class can be used to define functions with little syntactic overhead.\footnote{The \GHCmod{LambdaCase} extension of GHC is used to reduce the number of brackets that allows lambda's to be an argument to a function without brackets or explicit function application using \haskellinline{\$}}
+Using the \haskellinline{Function} type class can be used to define functions with little syntactic overhead.\footnote{The \GHCmod{BlockArguments} extension of GHC is used to reduce the number of brackets that allows lambda's to be an argument to a function without brackets}
The following listing shows an expression in the \gls{DSL} utilising two user-defined functions:
\begin{lstHaskell}
\begin{lrbox}{\LstBox}
\begin{lstHaskell}[frame=]
freshLabel :: Printer String
-tell :: MonadWriter w m => w -> m ()
- \end{lstHaskell}
+tell :: MonadWriter w m => w -> m ()\end{lstHaskell}
\end{lrbox}
\footnotetext{\usebox{\LstBox}}
To illustrate this, the instance for unary functions is shown, all other arities are implemented in similar fashion.
For example it can subvert module boundaries, thus accessing constructors that were hidden; access the structure of abstract types; and it may cause side effects during compilation because it is possible to call \haskellinline{IO} operations \citep{terei_safe_2012}.
To achieve the goal of embedding data types in a \gls{DSL} we refrain from using these \emph{unsafe} features.
-\subsubsection{Data types}
+\subsection{Data types}
Firstly, for all of \gls{HASKELL}'s AST elements, data types are provided that are mostly isomorphic to the actual data types used in the compiler.
With these data types, the entire syntax of a \gls{HASKELL} program can be specified.
Often, a data type is suffixed with the context, e.g.\ there is a \haskellinline{VarE} and a \haskellinline{VarP} for a variable in an expression or in a pattern respectively.
lamE ps es = LamE <$> sequence ps <*> es
\end{lstHaskell}
-\subsubsection{Splicing}
+\subsection{Splicing}
Special splicing syntax (\haskellinline{\$(...)}) marks functions for compile-time execution.
Other than that they always produce a value of an AST data type, they are regular functions.
Depending on the context and location of the splice, the result type is either a list of declarations, a type, an expression or a pattern.
| i<-[0..total-1]]] (varE f)
\end{lstHaskell}
-\subsubsection{Quasiquotation}
+\subsection{Quasiquotation}
Another key concept of \gls{TH} is Quasiquotation, the dual of splicing \citep{bawden_quasiquotation_1999}.
While it is possible to construct entire programs using the provided data types, it is a little cumbersome.
Using \emph{Oxford brackets} (\verb#[|# \ldots\verb#|]#) or single or double apostrophes, verbatim \gls{HASKELL} code can be entered that is converted automatically to the corresponding AST nodes easing the creation of language constructs.
Variables defined within quasiquotes are always fresh---as if defined with \haskellinline{newName}---but it is possible to capture identifiers using \haskellinline{mkName}.
For example, \haskellinline{[\|\\x->x\|]} translates to \haskellinline{newName "x" >>= \\x->lamE [varP x] (varE x)} and does not interfere with other \haskellinline{x}s already defined.
-\subsubsection{Reification}
+\subsection{Reification}
Reification is the act of querying the compiler for information about a certain name.
For example, reifying a type name results in information about the type and the corresponding AST nodes of the type's definition.
This information can then be used to generate code according to the structure of data types.
\begin{lrbox}{\LstBox}
\begin{lstHaskell}[frame=]
ifx :: String -> Q Exp -> Q Exp -> Q Exp
-ifx op a b = infixE (Just a) (varE (mkName op)) (Just b)
- \end{lstHaskell}
+ifx op a b = infixE (Just a) (varE (mkName op)) (Just b)\end{lstHaskell}
\end{lrbox}
\footnotetext{\usebox{\LstBox}}
For the sake of the argument we take a little shortcut here and assume that the interpretation of the \gls{DSL} supports lazy evaluation by using the host language as a metaprogramming language as well, allowing us to use functions in the host language to contstruct expressions in the \gls{DSL}.
\begin{lrbox}{\LstBox}
- \begin{lstHaskell}[frame=]
+ \begin{lstHaskell}[frame=,deletekeywords={if}]
class Support v where
if' :: v Bool -> v a -> v a -> v a
- bottom :: String -> v a
- \end{lstHaskell}
+ bottom :: String -> v a\end{lstHaskell}
\end{lrbox}
\footnotetext{\usebox{\LstBox}}
-\begin{lstHaskell}
+\begin{lstHaskell}[deletekeywords={if}]
program :: (ListDSL v, Support v, ...) => v Int
program
= fun \sum->(\l->if'(isNil l)
\end{lstHaskell}
Case expressions are transformed into constructors, deconstructors and constructor predicates, e.g.\ \haskellinline{case e1 of Cons hd tl -> e2; Nil -> e3;} is converted to:
-\begin{lstHaskell}
+\begin{lstHaskell}[deletekeywords={if}]
if' (isList e1)
(unCons e1 (\hd tl->e2))
(if' (isNil e1)
If the constructor matches, the deconstructor (\cref{mkcase_fcd:consdec}) is used to bind all names to the correct identifiers and evaluate the expression.
If the constructor does not match, the continuation (\haskellinline{\$rest}) is used (\cref{mkcase_fcd:consstart}).
-\begin{lstHaskell}[numbers=left]
+\begin{lstHaskell}[numbers=left,deletekeywords={if}]
mkCase :: Q Exp -> [(Q Pat, Q Exp)] -> Q Exp [+\label{mkcase_fcd:mkcase} +]
mkCase name cases = do
pats <- mapM fst cases [+ \label{mkcase_fcd:eval} +]
\Citet{egi_embedding_2022} extended \gls{HASKELL} to support non-free data type pattern matching---i.e.\ data type with no standard form, e.g.\ sets, graphs---using \gls{TH}.
Using quasiquotation, they make a complicated embedding of non-linear pattern matching available through a simple lens.
-\subsubsection{\texorpdfstring{\glsxtrlong{TTH}}{Typed Template Haskell}}\label{ssec_fcd:typed_template_haskell}
-\gls{TTH} is a very recent extension/alternative to normal \gls{TH} \citep{pickering_multi-stage_2019,xie_staging_2022}.
+\subsubsection{\texorpdfstring{\Glsxtrlong{TTH}}{Typed Template Haskell}}\label{ssec_fcd:typed_template_haskell}
+\Gls{TTH} is a very recent extension/alternative to normal \gls{TH} \citep{pickering_multi-stage_2019,xie_staging_2022}.
Where in \gls{TH} you can manipulate arbitrary parts of the syntax tree, add top-level splices of data types, definitions and functions, in \gls{TTH} the programmer can only splice expressions but the abstract syntax tree fragments representing the expressions are well-typed by construction instead of untyped.
\Citet{pickering_staged_2020} implemented staged compilation for the \emph{generics-sop} \citep{de_vries_true_2014} generics library to improve the efficiency of the code using \gls{TTH}.
\chapter{\texorpdfstring{\Glsxtrlong{TOP} for the \glsxtrlong{IOT}}{Task-oriented programming for the internet of things}}%
\label{chp:top4iot}
\begin{chapterabstract}
- \noindent This chapter:
+ This chapter compares traditional edge device programming to \gls{TOP} by:
\begin{itemize}
- \item introduces the problems with \gls{TOP} for the \gls{IOT}.
- \item shows how to create the \emph{Hello World!} application for microcontrollers using \gls{ARDUINO};
- \item extends this idea with multithreading, demonstrating the difficulty programming multi-tasking applications;
- \item describes a comparative variant in \gls{MTASK} and shows that upgrading to a multi-tasking variant is straightforward
- \item demonstrates that the complexity of running multiple tasks;
- \item and concludes with the history of \gls{MTASK}'s development.
+ \item introducing edge device programming;
+ \item showing how to create the \emph{Hello World!} application for microcontrollers using \gls{ARDUINO} and \gls{MTASK};
+ \item extending the idea to multithreading, uncovering problems using \gls{ARDUINO};
+ \item and demonstrating that upgrading to a multi-tasking variant is straightforward using \gls{MTASK}.
\end{itemize}
\end{chapterabstract}
The edge layer of \gls{IOT} systems predominantly consists of microcontrollers.
-Microcontrollers are tiny computers designed specifically for embedded applications.
-They therefore only have a soup\c{c}on of memory and have a slow processor.
-However, they also come with energy efficient sleep modes and have a lot of peripheral support such as \gls{GPIO} pins.
-Usually, programming microcontrollers requires an elaborate multi-step toolchain of compilation, linkage, binary image creation, and burning this image onto the flash memory of the microcontroller in order to compile and run a program.
-The programs are usually cyclic executives instead of tasks running in an operating system, i.e.\ there is only a single task that continuously runs on the bare metal.
+Microcontrollers are tiny computers designed specifically for embedded applications that much from regular computers in all aspects.
+They are much smaller; only have a fraction of the memory and processor speed; and run on different architectures.
+However, they have much more energy-efficient sleep modes, and support connecting and interfacing with peripherals such as sensors and actuators.
\Cref{tbl:mcu_laptop} compares the hardware properties of a typical laptop with two very popular microcontrollers.
+Usually, programming microcontrollers requires an elaborate multi-step toolchain of compilation, linkage, binary image creation, and burning this image onto the flash memory of the microcontroller in order to run a program.
+The programs are usually cyclic executives instead of tasks running in an \gls{OS}, i.e.\ there is only a single all-encompassing task that continuously runs on the bare metal.
+Hence, all tasks must be manually combined into a single program.
\begin{table}
- \caption{Hardware characteristics of typical microcontrollers compared to laptops.}%
+ \caption{Hardware characteristics of typical microcontrollers and a laptop.}%
\label{tbl:mcu_laptop}
+ \centering
\begin{tabular}{llll}
\toprule
& Laptop & Atmega328P & ESP8266\\
\end{table}
Different models of microcontrollers require their own vendor-provided drivers, hardware abstraction layer, compilers and \glspl{RTS}.
-There are many platforms that abstract away from this such as \gls{MBED} and \gls{ARDUINO}.
-\Gls{ARDUINO} is specifically designed for education and prototyping and hence used here to show traditional microcontroller programming.
-
+To structure this jungle of tools, platforms exist that provide abstraction layers over the low-level toolchains such as \gls{ARDUINO}.
+It is specifically designed for education and prototyping and hence used here to illustrate traditional microcontroller programming.
The popular \gls{ARDUINO} \ccpp{} dialect and accompanying libraries provide an abstraction layer for common microcontroller behaviour allowing the programmer to program multiple types of microcontrollers using a single language.
-Originally it was designed for the in-house developed open-source hardware with the same name but the setup allows porting to many architectures.
+Originally it was designed for the in-house developed open-source hardware with the same name but the setup allows porting to many architectures by vendor-provided \emph{cores}.
It provides an \gls{IDE} and toolchain automation to perform all steps of the toolchain with a single command.
\section{\texorpdfstring{\Glsxtrshort{TOP} for the \glsxtrshort{IOT}}{TOP for the IoT}}
-\Gls{TOP} is a programming paradigm that allows multi-tier systems to be generated from a single declarative source.
-\Gls{ITASK} is a general-purpose \gls{TOP} system for programming distributed web applications.
-These distributed web applications often form the core of \gls{IOT} applications as well but integrating these devices in \gls{ITASK} is not straightforward.
-\Gls{ITASK} targets relatively fast but energy-hungry systems with large amounts of \gls{RAM} and a speedy connections.
+\Gls{TOP} is a programming paradigm that allows multi-tier interactive systems to be generated from a single declarative source.
+\Gls{ITASK} is a general-purpose \gls{TOP} system for programming interactive distributed web applications.
+These distributed web applications often form the core of the top two layers of \gls{IOT} applications.
+Integrating the perception layer, the edge devices, in \gls{ITASK} also is not straightforward.
+\Gls{ITASK} targets relatively fast but energy-hungry systems with large amounts of \gls{RAM} and a speedy connection.
Edge devices in \gls{IOT} systems are typically slow but energy efficient and do not have the memory to run the naturally heap-heavy functional programs that \gls{ITASK} programs are.
-\Gls{MTASK} bridges this gap by providing a \gls{TOP} \gls{DSL} for \gls{IOT} edge devices that can, because domain-specific knowledge is embedded in the language and execution platform, run on hardware with much less memory and processor speed.
+\Gls{MTASK} bridges this gap by providing a \gls{TOP} \gls{DSL} for \gls{IOT} edge devices.
+Domain-specific knowledge is embedded in the language and execution platform, drastically lowering the hardware requirements.
The following sections compare traditional microcontroller programming with programming the devices using \gls{MTASK}.
\section{Hello world!}
Traditionally, the first program that one writes when trying a new language is the so-called \emph{Hello World!} program.
This program has the single task of printing the text \emph{Hello World!} to the screen and exiting again, useful to become familiarised with the syntax and verify that the toolchain and runtime environment is working.
-On microcontrollers, there usually is no screen for displaying text.
-Nevertheless, almost always there is a built-in monochrome $1\times1$ pixel screen, namely \pgls{LED}.
+Microcontrollers usually do not come with screens in the traditional sense.
+Nevertheless, almost always there is a built-in monochrome \numproduct{1x1} pixel screen, namely the built-in \gls{LED}. %chktex 29
The \emph{Hello World!} equivalent on microcontrollers blinks this \gls{LED}.
-\Cref{lst:arduinoBlink} shows how the logic of a blink program might look when using \gls{ARDUINO}'s \ccpp{} dialect.
-Every \gls{ARDUINO} program contains a \arduinoinline{setup} and a \arduinoinline{loop} function.
+Using \gls{ARDUINO}'s \ccpp{} dialect to create the blink program results in the code seen in \citelisting{\ref{lst:arduinoBlink}}.
+\Gls{ARDUINO} programs are implemented as cyclic executives and hence, each program defines a \arduinoinline{setup} and a \arduinoinline{loop} function.
The \arduinoinline{setup} function is executed only once on boot, the \arduinoinline{loop} function is continuously called afterwards and contains the event loop.
-After setting the \gls{GPIO} pin to the correct mode, blink's \arduinoinline{loop} function alternates the state of the pin representing the \gls{LED} between \arduinoinline{HIGH} and \arduinoinline{LOW}, turning the \gls{LED} off and on respectively.
-In between it waits for \qty{500}{\ms} so that the blinking is actually visible for the human eye.
-
-Translating the traditional blink program to \gls{MTASK} can almost be done by simply substituting some syntax as seen in \cref{lst:blinkImp}.
-E.g.\ \arduinoinline{digitalWrite} becomes \cleaninline{writeD}, literals are prefixed with \cleaninline{lit} and the pin to blink is changed to represent the actual pin for the builtin \gls{LED} of the device used in the exercises.
-In contrast to the imperative \gls{CPP} dialect, \gls{MTASK} is a \gls{TOP} language and therefore there is no such thing as a loop, only task combinators to combine tasks.
-To simulate a loop, the \cleaninline{rpeat} task combinator can be used as this task combinator executes the argument task and, when stable, reinstates it.
-The body of the \cleaninline{rpeat} contains similarly named tasks to write to the pins and to wait in between.
-The tasks are connected using the sequential \cleaninline{>>|.} combinator that for all current intents and purposes executes the tasks after each other.
+In the blink example, the \arduinoinline{setup} function only contains code for setting the \gls{GPIO} pin to the correct mode.
+The \arduinoinline{loop} function alternates the state of the pin representing the \gls{LED} between \arduinoinline{HIGH} and \arduinoinline{LOW}, turning the \gls{LED} off and on respectively.
+In between, it waits \qty{500}{\ms} so that the blinking is actually visible for the human eye.
-\begin{figure}[ht]
- \begin{subfigure}[b]{.5\linewidth}
- \begin{lstArduino}[caption={Blink program.},label={lst:arduinoBlink}]
+\begin{lstArduino}[caption={Blinking an \gls{LED}.},label={lst:arduinoBlink}]
void setup() {
pinMode(D2, OUTPUT);
}
digitalWrite(D2, LOW);
delay(500);
}\end{lstArduino}
- \end{subfigure}%
- \begin{subfigure}[b]{.5\linewidth}
- \begin{lstClean}[caption={Blink program.},label={lst:blinkImp}]
+
+\subsection{Blinking the \texorpdfstring{\glsxtrshort{LED}}{LED} in \texorpdfstring{\gls{MTASK}}{mTask}.}
+Naively translating the traditional blink program to \gls{MTASK} can be done by simply substituting some syntax as seen in \citelisting{\ref{lst:blinkImp}}.
+E.g.\ \arduinoinline{digitalWrite} becomes \cleaninline{writeD}, literals are prefixed with \cleaninline{lit} and the pin to blink is changed to represent the actual pin for the builtin \gls{LED} of the device used in the exercises.
+In contrast to the imperative \gls{CPP} dialect, \gls{MTASK} is a \gls{TOP} language and therefore there is no such thing as a loop, only task combinators to combine tasks.
+To simulate a loop, the \cleaninline{rpeat} task combinator can be used as this task combinator executes the argument task and, when stable, reinstates it.
+The body of the \cleaninline{rpeat} contains similarly named tasks to write to the pins and to wait in between.
+The tasks are connected using the sequential \cleaninline{>>|.} combinator that for all current intents and purposes executes the tasks after each other.
+\begin{lstClean}[caption={Blinking the \gls{LED}.},label={lst:blinkImp}]
blink :: Main (MTask v ()) | mtask v
blink =
declarePin D2 PMOutput \d2->
writeD d2 true
>>|. delay (lit 500)
>>|. writeD d2 false
- >>|. delay (lit 500)
- )
-}\end{lstClean}
- \end{subfigure}
-\end{figure}
+ >>|. delay (lit 500))
+ }
+\end{lstClean}
\section{Multi tasking}
Now say that we want to blink multiple blinking patterns on different \glspl{LED} concurrently.
For example, blink three \glspl{LED} connected to \gls{GPIO} pins $1,2$ and $3$ at intervals of \qtylist{500;300;800}{\ms}.
-Intuitively you want to lift the blinking behaviour to a function and call this function three times with different parameters as done in \cref{lst:blinkthreadno}
+Intuitively you would want to lift the blinking behaviour to a function and call this function three times with different parameters as shown in \cref{lst:blinkthreadno}.
\begin{lstArduino}[caption={Naive approach to multiple blinking patterns.},label={lst:blinkthreadno}]
void setup () { ... }
}\end{lstArduino}
Unfortunately, this does not work because the \arduinoinline{delay} function blocks all further execution.
-The resulting program will blink the \glspl{LED} after each other instead of at the same time.
+The resulting program blinks the \glspl{LED} after each other instead of at the same time.
To overcome this, it is necessary to slice up the blinking behaviour in very small fragments so it can be manually interleaved \citep{feijs_multi-tasking_2013}.
-Listing~\ref{lst:blinkthread} shows how three different blinking patterns might be achieved in \gls{ARDUINO} using the slicing method.
-If we want the blink function to be a separate parametrizable function we need to explicitly provide all references to the required state.
+\Cref{lst:blinkthread} shows how three different blinking patterns could be implemented in \gls{ARDUINO} using the slicing method.
+If we want the blink function to be a separate parametrisable function we need to explicitly provide all references to the required global state.
Furthermore, the \arduinoinline{delay} function can not be used and polling \arduinoinline{millis} is required.
The \arduinoinline{millis} function returns the number of milliseconds that have passed since the boot of the microcontroller.
-Some devices use very little energy when in \arduinoinline{delay} or sleep state.
-Resulting in \arduinoinline{millis} potentially affects power consumption since the processor is basically busy looping all the time.
-In the simple case of blinking three \glspl{LED} on fixed intervals, it might be possible to calculate the delays in advance using static analysis and generate the appropriate \arduinoinline{delay} code.
+If the delay is long enough, it may also be possible to put the processor in sleep mode, reducing the power consumption drastically.
+Hence, using \arduinoinline{millis} potentially affects power consumption since the processor is basically busy looping all the time.
+Manually combining tasks into a single program is very error prone, requires a lot of pointer juggling, and generally results into spaghetti code.
+Furthermore, it is very difficult to represent dependencies between threads, often state machines have to be explicitly programmed by hand to achieve this.
+In the simple case of blinking three \glspl{LED} according to fixed intervals, it is possible to calculate the delays in advance using static analysis and generate the appropriate \arduinoinline{delay} calls.
Unfortunately, this is very hard when for example the blinking patterns are determined at runtime.
\begin{lstArduino}[label={lst:blinkthread},caption={Threading three blinking patterns.}]
blink(D3, 800, &led3, &st1);
}\end{lstArduino}
-This method is very error prone, requires a lot of pointer juggling and generally results into spaghetti code.
-Furthermore, it is very difficult to represent dependencies between threads, often state machines have to be explicitly programmed by hand to achieve this.
-
\subsection{Multi tasking in \texorpdfstring{\gls{MTASK}}{mTask}}
-The \cleaninline{delay} \emph{task} does not block the execution but \emph{just} emits no value when the target waiting time has not yet passed and emits a stable value when the time is met.
-In contrast, the \arduinoinline{delay()} \emph{function} on the \gls{ARDUINO} is blocking which prohibits interleaving.
-To make code reuse possible and make the implementation more intuitive, the blinking behaviour is lifted to a recursive function instead of using the imperative \cleaninline{rpeat} construct.
-The function is parametrized with the current state, the pin to blink and the waiting time.
+In contrast to the \arduinoinline{delay} function in \gls{ARDUINO}, \gls{MTASK}'s \cleaninline{delay} \emph{task} does not block the execution.
+It has no observable value until the target waiting time has passed, and thence is \emph{stable}.
+To make code reuse possible and make the implementation more intuitive, the blinking behaviour is lifted to a recursive function instead of using the imperatively looking \cleaninline{rpeat} task combinator.
+There is no global state, the function is parametrized with the current status, the pin to blink and the waiting time.
Creating recursive functions like this is not possible in the \gls{ARDUINO} language because the program would run out of stack in an instant and nothing can be interleaved.
-With a parallel combinator, tasks can be executed in an interleaved fashion.
+With a parallel combinator, tasks are executed in an interleaved fashion.
Therefore, blinking three different blinking patterns is as simple as combining the three calls to the \cleaninline{blink} function with their arguments as seen in \cref{lst:blinkthreadmtask}.
% VimTeX: SynIgnore on
-\begin{lstClean}[label={lst:blinkthreadmtask},caption={Threaded blinking.}]
+\begin{lstClean}[label={lst:blinkthreadmtask},caption={Threading three blinking patterns.}]
blinktask :: MTask v () | mtask v
blinktask =
declarePin D1 PMOutput \d1->
\section{Conclusion}
The edge layer of \gls{IOT} systems is powered by microcontrollers.
+Microcontrollers have significantly different characteristics to regular computers.
Programming them happens through compiled firmwares using low-level imperative programming languages.
Due to the lack of an \gls{OS}, writing applications that perform multiple tasks at the same time is error prone, and complex; and requires a lot of boilerplate and manual scheduling code.
With the \gls{MTASK} system, a \gls{TOP} programming language for \gls{IOT} edge devices, this limitation can be overcome.
-\todo{uit\-breiden}
-
-\begin{subappendices}
-\section{History of \texorpdfstring{\gls{MTASK}}{mTask}}
-The development of \gls{MTASK} or its predecessors has been going on for almost seven years now though it really set off during my master's thesis.
-This section provides an exhaustive overview of the work on \gls{MTASK} and its predecessors.
-
-\subsection*{Generating \texorpdfstring{\ccpp{}}{\ccpp{}} code}
-A first throw at a class-based shallowly \gls{EDSL} for microcontrollers was made by \citet{plasmeijer_shallow_2016}.
-The language was called \gls{ARDSL} and offered a type safe interface to \gls{ARDUINO} \gls{CPP} dialect.
-A \gls{CPP} code generation backend was available together with an \gls{ITASK} simulation backend.
-There was no support for tasks nor even functions.
-Some time later in the 2015 \gls{CEFP} summer school, an extended version was created that allowed the creation of imperative tasks, local \glspl{SDS} and the usage of functions \citep{koopman_type-safe_2019}.
-The name then changed from \gls{ARDSL} to \gls{MTASK}.
-
-\subsection*{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}
-\Citet{lubbers_task_2017} extended this in his Master's Thesis by adding integration with \gls{ITASK} and a bytecode compiler to the language.
-\Gls{SDS} in \gls{MTASK} could be accessed on the \gls{ITASK} server.
-In this way, entire \gls{IOT} systems could be programmed from a single source.
-However, this version used a simplified version of \gls{MTASK} without functions.
-This was later improved upon by creating a simplified interface where \glspl{SDS} from \gls{ITASK} could be used in \gls{MTASK} and the other way around \citep{lubbers_task_2018}.
-It was shown by \citet{amazonas_cabral_de_andrade_developing_2018} that it was possible to build real-life \gls{IOT} systems with this integration.
-Moreover, a course on the \gls{MTASK} simulator was provided at the 2018 \gls{CEFP}\slash\gls{3COWS} winter school in Ko\v{s}ice, Slovakia \citep{koopman_simulation_2018}.
-
-\subsection*{Transition to \texorpdfstring{\gls{TOP}}{TOP}}
-The \gls{MTASK} language as it is now was introduced in 2018 \citep{koopman_task-based_2018}.
-This paper updated the language to support functions, simple tasks, and \glspl{SDS} but still compiled to \gls{ARDUINO} \gls{CPP} code.
-Later the byte code compiler and \gls{ITASK} integration was added to the language \citep{lubbers_interpreting_2019}.
-Moreover, it was shown that it is very intuitive to write microcontroller applications in a \gls{TOP} language \citep{lubbers_multitasking_2019}.
-One reason for this is that a lot of design patterns that are difficult using standard means are for free in \gls{TOP} (e.g.\ multithreading).
-In 2019, the \gls{CEFP}\slash\gls{3COWS} summer school in Budapest, Hungary hosted a course on developing \gls{IOT} applications with \gls{MTASK} as well \citep{lubbers_writing_2019}.
-
-\subsection*{\texorpdfstring{\Glsxtrshort{TOP}}{TOP}}
-In 2022, the SusTrainable summer school in Rijeka, Croatia hosted a course on developing greener \gls{IOT} applications using \gls{MTASK} as well \citep{lubbers_green_2022}.
-Several students worked on extending \gls{MTASK} with many useful features:
-\Citet{van_der_veen_mutable_2020} did preliminary work on a green computing analysis, built a simulator, and explored the possibilities for adding bounded datatypes; \citet{de_boer_secure_2020} investigated the possibilities for secure communication channels; \citeauthor{crooijmans_reducing_2021} \citeyearpar{crooijmans_reducing_2021,crooijmans_reducing_2022} added abstractions for low-power operation to \gls{MTASK} such as hardware interrupts and power efficient scheduling; and \citet{antonova_mtask_2022} defined a preliminary formal semantics for a subset of \gls{MTASK}.
-
-\subsection*{\texorpdfstring{\gls{MTASK}}{mTask} in practise}
-Funded by the Radboud-Glasgow Collaboration Fund, collaborative work was executed with Phil Trinder, Jeremy Singer, and Adrian Ravi Kishore Ramsingh.
-An existing smart campus application was developed using \gls{MTASK} and quantitively and qualitatively compared to the original application that was developed using a traditional \gls{IOT} stack \citep{lubbers_tiered_2020}.
-This research was later extended to include a four-way comparison: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK}, and \gls{MTASK} \citep{lubbers_could_2022}.
-Currently, power efficiency behaviour of traditional versus \gls{TOP} \gls{IOT} stacks is being compared as well adding a \gls{FREERTOS} implementation to the mix as well.
-
-\subsection*{Future work}
-Plans for extensions and improvements include exploring integrating \gls{TINYML} into \gls{MTASK}; adding intermittent computing support to \gls{MTASK}; and extending the formal semantics to cover the entirety of the language.
-In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK} as well.
-
-\end{subappendices}
+As much domain-specific knowledge is built into the language and the \gls{RTS}, the hardware requirements can be kept relatively low while maintaining a high abstraction level.
+\todo{moet dit uitgebreider?}
\input{subfilepostamble}
\end{document}
This chapter wraps up the monograph by:
\begin{itemize}
\item providing a conclusion;
- \item and an overview of the related work;
+ \item an overview of the related work;
+ \item and giving a history of the \gls{MTASK} system.
\end{itemize}
\end{chapterabstract}
\section{Finale}
+\todo[inline]{Conclusion}
\section{Related work}
The novelties of the \gls{MTASK} system can be compared to existing systems in several categories.
\subsection{Multi tasking}\label{sec:related_multi}
+\section{History of \texorpdfstring{\gls{MTASK}}{mTask}}
+The development of \gls{MTASK} or its predecessors has been going on for almost seven years now though it really set off during my master's thesis.
+This section provides an exhaustive overview of the work on \gls{MTASK} and its predecessors.
+
+\subsection*{Generating \texorpdfstring{\ccpp{}}{\ccpp{}} code}
+A first throw at a class-based shallowly \gls{EDSL} for microcontrollers was made by \citet{plasmeijer_shallow_2016}.
+The language was called \gls{ARDSL} and offered a type safe interface to \gls{ARDUINO} \gls{CPP} dialect.
+A \gls{CPP} code generation backend was available together with an \gls{ITASK} simulation backend.
+There was no support for tasks nor even functions.
+Some time later in the 2015 \gls{CEFP} summer school, an extended version was created that allowed the creation of imperative tasks, local \glspl{SDS} and the usage of functions \citep{koopman_type-safe_2019}.
+The name then changed from \gls{ARDSL} to \gls{MTASK}.
+
+\subsection*{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}
+\Citet{lubbers_task_2017} extended this in his Master's Thesis by adding integration with \gls{ITASK} and a bytecode compiler to the language.
+\Gls{SDS} in \gls{MTASK} could be accessed on the \gls{ITASK} server.
+In this way, entire \gls{IOT} systems could be programmed from a single source.
+However, this version used a simplified version of \gls{MTASK} without functions.
+This was later improved upon by creating a simplified interface where \glspl{SDS} from \gls{ITASK} could be used in \gls{MTASK} and the other way around \citep{lubbers_task_2018}.
+It was shown by \citet{amazonas_cabral_de_andrade_developing_2018} that it was possible to build real-life \gls{IOT} systems with this integration.
+Moreover, a course on the \gls{MTASK} simulator was provided at the 2018 \gls{CEFP}\slash\gls{3COWS} winter school in Ko\v{s}ice, Slovakia \citep{koopman_simulation_2018}.
+
+\subsection*{Transition to \texorpdfstring{\gls{TOP}}{TOP}}
+The \gls{MTASK} language as it is now was introduced in 2018 \citep{koopman_task-based_2018}.
+This paper updated the language to support functions, simple tasks, and \glspl{SDS} but still compiled to \gls{ARDUINO} \gls{CPP} code.
+Later the byte code compiler and \gls{ITASK} integration was added to the language \citep{lubbers_interpreting_2019}.
+Moreover, it was shown that it is very intuitive to write microcontroller applications in a \gls{TOP} language \citep{lubbers_multitasking_2019}.
+One reason for this is that a lot of design patterns that are difficult using standard means are for free in \gls{TOP} (e.g.\ multithreading).
+In 2019, the \gls{CEFP}\slash\gls{3COWS} summer school in Budapest, Hungary hosted a course on developing \gls{IOT} applications with \gls{MTASK} as well \citep{lubbers_writing_2019}.
+
+\subsection*{\texorpdfstring{\Glsxtrshort{TOP}}{TOP}}
+In 2022, the SusTrainable summer school in Rijeka, Croatia hosted a course on developing greener \gls{IOT} applications using \gls{MTASK} as well \citep{lubbers_green_2022}.
+Several students worked on extending \gls{MTASK} with many useful features:
+\Citet{van_der_veen_mutable_2020} did preliminary work on a green computing analysis, built a simulator, and explored the possibilities for adding bounded datatypes; \citet{de_boer_secure_2020} investigated the possibilities for secure communication channels; \citeauthor{crooijmans_reducing_2021} \citeyearpar{crooijmans_reducing_2021,crooijmans_reducing_2022} added abstractions for low-power operation to \gls{MTASK} such as hardware interrupts and power efficient scheduling; and \citet{antonova_mtask_2022} defined a preliminary formal semantics for a subset of \gls{MTASK}.
+
+\subsection*{\texorpdfstring{\gls{MTASK}}{mTask} in practise}
+Funded by the Radboud-Glasgow Collaboration Fund, collaborative work was executed with Phil Trinder, Jeremy Singer, and Adrian Ravi Kishore Ramsingh.
+An existing smart campus application was developed using \gls{MTASK} and quantitively and qualitatively compared to the original application that was developed using a traditional \gls{IOT} stack \citep{lubbers_tiered_2020}.
+This research was later extended to include a four-way comparison: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK}, and \gls{MTASK} \citep{lubbers_could_2022}.
+Currently, power efficiency behaviour of traditional versus \gls{TOP} \gls{IOT} stacks is being compared as well adding a \gls{FREERTOS} implementation to the mix as well.
+
+\section{Future work}
+Plans for extensions and improvements include exploring integrating \gls{TINYML} into \gls{MTASK}; adding intermittent computing support to \gls{MTASK}; and extending the formal semantics to cover the entirety of the language.
+In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK} as well.
+
\input{subfilepostamble}
\end{document}
repositories / phd-thesis.git / commitdiff