updates

[phd-thesis.git] / top / top.tex

diff --git a/top/top.tex b/top/top.tex
index 619789f..3f18e5a 100644 (file)
--- a/top/top.tex
+++ b/top/top.tex
@@ -7,30 +7,38 @@
        \pagenumbering{arabic}
 }{}
 
        \pagenumbering{arabic}
 }{}
 

-\chapter{Introduction to \texorpdfstring{\gls{IOT}}{IoT} programming}%
+\chapter{Introduction to \texorpdfstring{\glsxtrshort{IOT}}{IoT} device programming}%

 \label{chp:top4iot}
 \todo{betere chapter naam}
 \begin{chapterabstract}
        This chapter introduces \gls{MTASK} and puts it into perspective compared to traditional microprocessor programming.
 \end{chapterabstract}
 
 \label{chp:top4iot}
 \todo{betere chapter naam}
 \begin{chapterabstract}
        This chapter introduces \gls{MTASK} and puts it into perspective compared to traditional microprocessor programming.
 \end{chapterabstract}
 

+The edge layer of \gls{IOT} system mostly consists of microprocessors that require a different method of programming.
+Usually, programming microprocessors requires an elaborate multi-step toolchain of compilation, linkage, binary image creation, and burning this image onto the flash memory of the microprocessor 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.
+Each type of microprocessors comes with vendor-provided drivers, compilers and \glspl{RTS} but there are many platform that abstract away from this such as \gls{MBED} and \gls{ARDUINO} of which \gls{ARDUINO} is specifically designed for education and prototyping and hence used here.
+The popular \gls{ARDUINO} \gls{C}\slash\gls{CPP} dialect and accompanying libraries provide an abstraction layer for common microprocessor behaviour allowing the programmer to program multiple types of microprocessors 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.
+It provides an \gls{IDE} and toolchain automation to perform all steps of the toolchain with a single command.
+
+\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.
 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 microprocessors, there often is no screen for displaying text.
-Nevertheless, almost always there is a monochrome $1\times1$ pixel screen, namely an---often builtin---\gls{LED}.
+On microprocessors, there usually is no screen for displaying text.
+Nevertheless, almost always there is a built-in monochrome $1\times1$ pixel screen, namely an \gls{LED}.

 The \emph{Hello World!} equivalent on microprocessors blinks this \gls{LED}.
 
 The \emph{Hello World!} equivalent on microprocessors blinks this \gls{LED}.
 

-\Cref{lst:arduinoBlink} shows how the logic of a blink program might look when using \gls{ARDUINO}'s \gls{CPP} dialect.
+\Cref{lst:arduinoBlink} shows how the logic of a blink program might look when using \gls{ARDUINO}'s \gls{C}\slash\gls{CPP} dialect.

 Every \gls{ARDUINO} program contains 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.
 Every \gls{ARDUINO} program contains 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 500 milliseconds so that the blinking is actually visible for the human eye.
-Compiling this results in a binary firmware that needs to be flashed onto the program memory.
+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.
 
 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 can be used, this task executes the argument task and, when stable, reinstates it.
+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.
 
 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.
 


@@ -46,7 +54,8 @@ void loop() {
        delay(500);
        digitalWrite(D2, LOW);
        delay(500);
        delay(500);
        digitalWrite(D2, LOW);
        delay(500);

-}\end{lstArduino}
+}
+               \end{lstArduino}

        \end{subfigure}%
        \begin{subfigure}[b]{.5\linewidth}
                \begin{lstClean}[caption={Blink program.},label={lst:blinkImp}]
        \end{subfigure}%
        \begin{subfigure}[b]{.5\linewidth}
                \begin{lstClean}[caption={Blink program.},label={lst:blinkImp}]


@@ -59,13 +68,14 @@ blink =
                >>|. writeD d2 false
                >>|. delay (lit 500)
        )
                >>|. writeD d2 false
                >>|. delay (lit 500)
        )

-}\end{lstClean}
+}
+               \end{lstClean}

        \end{subfigure}
 \end{figure}
 
 \section{Threaded blinking}
 Now say that we want to blink multiple blinking patterns on different \glspl{LED} concurrently.
        \end{subfigure}
 \end{figure}
 
 \section{Threaded blinking}
 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 $500,300$ and $800$ milliseconds.
+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}
 
 \begin{lstArduino}[caption={Naive approach to multiple blinking patterns.},label={lst:blinkthreadno}]
 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}
 
 \begin{lstArduino}[caption={Naive approach to multiple blinking patterns.},label={lst:blinkthreadno}]


@@ -86,7 +96,7 @@ void loop() {
 
 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.
 
 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.

-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}.
+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.
 Furthermore, the \arduinoinline{delay} function can not be used and polling \arduinoinline{millis} is required.
 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.
 Furthermore, the \arduinoinline{delay} function can not be used and polling \arduinoinline{millis} is required.


@@ -142,35 +152,76 @@ blinktask =
        }\end{lstClean}
 % VimTeX: SynIgnore off
 
        }\end{lstClean}
 % VimTeX: SynIgnore off
 

-\chapter{The \texorpdfstring{\gls{MTASK}}{mTask} \texorpdfstring{\gls{DSL}}{DSL}}%
+\section{\texorpdfstring{\Gls{MTASK}}{MTask} history}
+\subsection{Generating \texorpdfstring{\gls{C}/\gls{CPP}}{C/C++} code}
+A first throw at a class-based shallowly \gls{EDSL} for microprocessors 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 or even functions.
+Some time later in the 2015 \gls{CEFP} summer school, an extended version was created that allowed the creation of imperative tasks, \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}/\gls{3COWS} winter school in Ko\v{s}ice, Slovakia \citep{koopman_simulation_2018}.
+
+\section{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, tasks and \glspl{SDS} but still compiled to \gls{CPP} \gls{ARDUINO} code.
+Later the bytecode 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 microprocessor 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} 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 (the lecture notes are to be written).
+Several students worked on extending \gls{MTASK} with many useful features:
+\Citet{veen_van_der_mutable_2020} did preliminary work on a green computer analysis, built a simulator and explored the possibilities for adding bounded datatypes; \citet{boer_de_secure_2020} investigated the possibilities for secure communication channels; and \citet{crooijmans_reducing_2021} added abstractions for low-power operation to \gls{MTASK} such as hardware interrupts and power efficient scheduling (resulting in a paper as well \citet{crooijmans_reducing_2022}).
+\Citet{antonova_mtask_2022} defined a preliminary formal semantics for a subset of \gls{MTASK}.
+Moreover, plans for student projects and improvements include exploring integrating \gls{TINYML} into \gls{MTASK}; and adding intermittent computing support to \gls{MTASK}.
+
+In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK} as well.
+
+\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.
+
+\chapter{The \texorpdfstring{\gls{MTASK}}{mTask} \texorpdfstring{\glsxtrshort{DSL}}{DSL}}%

 \label{chp:mtask_dsl}
 \begin{chapterabstract}
 This chapter serves as a complete guide to the \gls{MTASK} language, from an \gls{MTASK} programmer's perspective.
 \end{chapterabstract}
 
 \label{chp:mtask_dsl}
 \begin{chapterabstract}
 This chapter serves as a complete guide to the \gls{MTASK} language, from an \gls{MTASK} programmer's perspective.
 \end{chapterabstract}
 

-The \gls{MTASK} system is a \gls{TOP} programming environment for programming microprocessors.
-It is implemented as an\gls{EDSL} in \gls{CLEAN} using class-based---or tagless-final---embedding (See \cref{ssec:tagless}).
-Due to the nature of the embedding technique, it is possible to have multiple interpretations of---or views on---programs written in the \gls{MTASK} language.
+The \gls{MTASK} system is a complete \gls{TOP} programming environment for programming microprocessors.
+It is implemented as an \gls{EDSL} in \gls{CLEAN} using class-based---or tagless-final---embedding (see \cref{sec:tagless-final_embedding}).
+
+Due to the nature of the embedding technique, it is possible to have multiple views on-programs written in the \gls{MTASK} language.

 The following interpretations are available for \gls{MTASK}.
 
 The following interpretations are available for \gls{MTASK}.
 

-\begin{itemize}
-       \item Pretty printer
+\begin{description}
+       \item[Pretty printer]

 
                This interpretation converts the expression to a string representation.
 
                This interpretation converts the expression to a string representation.

-       \item Simulator
+       \item[Simulator]

 
                The simulator converts the expression to a ready-for-work \gls{ITASK} simulation in which the user can inspect and control the simulated peripherals and see the internal state of the tasks.
 
                The simulator converts the expression to a ready-for-work \gls{ITASK} simulation in which the user can inspect and control the simulated peripherals and see the internal state of the tasks.

-       \item Compiler
+       \item[Byte code compiler]

 
 

-               The compiler compiles the \gls{MTASK} program at runtime to a specialised bytecode.
+               The compiler compiles the \gls{MTASK} program at runtime to a specialised byte code.

                Using a handful of integration functions and tasks, \gls{MTASK} tasks can be executed on microprocessors and integrated in \gls{ITASK} as if they were regular \gls{ITASK} tasks.
                Furthermore, with special language constructs, \glspl{SDS} can be shared between \gls{MTASK} and \gls{ITASK} programs.
                Using a handful of integration functions and tasks, \gls{MTASK} tasks can be executed on microprocessors and integrated in \gls{ITASK} as if they were regular \gls{ITASK} tasks.
                Furthermore, with special language constructs, \glspl{SDS} can be shared between \gls{MTASK} and \gls{ITASK} programs.

-\end{itemize}
+\end{description}

 
 When using the compiler interpretation in conjunction with the \gls{ITASK} integration, \gls{MTASK} is a heterogeneous \gls{DSL}.
 
 When using the compiler interpretation in conjunction with the \gls{ITASK} integration, \gls{MTASK} is a heterogeneous \gls{DSL}.

-I.e.\ some components---e.g.\ the \gls{RTS} on the microprocessor---is largely unaware of the other components in the system.
-Furthermore, it is executed on a completely different architecture.
-The \gls{MTASK} language consists of a host language---a simply-typed $\lambda$-calculua with support for some basic types, function definition and data types (see \cref{sec:expressions})---enriched with a task language (see \cref{sec:top}).
+I.e.\ some components---e.g.\ the \gls{RTS} on the microprocessor---is largely unaware of the other components in the system, and it is executed on a completely different architecture.
+The \gls{MTASK} language is an enriched simply-typed $\lambda$-calculus with support for some basic types, arithmetic operations, and function definition; and a task language (see \cref{sec:top}).

 
 \section{Types}
 To leverage the type checker of the host language, types in the \gls{MTASK} language are expressed as types in the host language, to make the language type safe.
 
 \section{Types}
 To leverage the type checker of the host language, types in the \gls{MTASK} language are expressed as types in the host language, to make the language type safe.


@@ -199,37 +250,41 @@ The class constraints for values in \gls{MTASK} are omnipresent in all functions
        \label{tbl:mtask-c-datatypes}
 \end{table}
 
        \label{tbl:mtask-c-datatypes}
 \end{table}
 

-The \gls{MTASK} language consists of a core collection of type classes bundled in the type class \cleaninline{class mtask}.
+\Cref{lst:constraints} contains the definitions for the auxiliary types and type constraints (such as \cleaninline{type} an \cleaninline{basicType}) that are used to construct \gls{MTASK} expressions.
+The \gls{MTASK} language interface consists of a core collection of type classes bundled in the type class \cleaninline{class mtask}.

 Every interpretation implements the type classes in the \cleaninline{mtask} class
 Every interpretation implements the type classes in the \cleaninline{mtask} class

-There are also \gls{MTASK} extensions that not every interpretation implements such as peripherals and integration with \gls{ITASK}.
-
-\Cref{lst:constraints} contains the definitions for the type constraints and shows some example type signatures for typical \gls{MTASK} expressions and tasks.
-\todo{uitleggen}
-
+There are also \gls{MTASK} extensions that not every interpretation implements such as peripherals and \gls{ITASK} integration.

 \begin{lstClean}[caption={Classes and class collections for the \gls{MTASK} language.},label={lst:constraints}]
 \begin{lstClean}[caption={Classes and class collections for the \gls{MTASK} language.},label={lst:constraints}]

-:: Main a = { main :: a }
-:: In a b = (In) infix 0 a b
-

 class type t | iTask, ... ,fromByteCode, toByteCode t
 class basicType t | type t where ...
 
 class mtask v | expr, ..., int, real, long v
 
 class type t | iTask, ... ,fromByteCode, toByteCode t
 class basicType t | type t where ...
 
 class mtask v | expr, ..., int, real, long v
 

-someExpr :: v Int | mtask v
-someExpr = ...
+\end{lstClean}
+
+Sensors, \glspl{SDS}, functions, \etc{} may only be defined at the top level.
+The \cleaninline{Main} type is used that is used to distinguish the top level from the main expression.
+Some top level definitions, such as functions, 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 as can be seen in \cleaninline{someTask} (\cref{lst:mtask_types}).

 
 

-someTask :: MTask v Int | mtask v
+\begin{lstClean}[caption={Example task and auxiliary types in the \gls{MTASK} language.},label={lst:mtask_types}]
+:: Main a = { main :: a }
+:: In a b = (In) infix 0 a b
+
+someTask :: MTask v Int | mtask v & liftsds v & sensor1 v & ...

 someTask =
        sensor1 config1 \sns1->
        sensor2 config2 \sns2->
 someTask =
        sensor1 config1 \sns1->
        sensor2 config2 \sns2->

-          fun \fun1= ( ... )
+          sds \s1=initial
+       In liftsds \s2=someiTaskSDS
+       In fun \fun1= ( ... )

        In fun \fun2= ( ... )
        In fun \fun2= ( ... )

-       In {main=mainexpr}
+       In { main = mainexpr }

 \end{lstClean}
 
 \section{Expressions}\label{sec:expressions}
 \Cref{lst:expressions} shows the \cleaninline{expr} class containing the functionality to lift values from the host language to the \gls{MTASK} language (\cleaninline{lit}); perform number and boolean arithmetics; do comparisons; and conditional execution.
 \end{lstClean}
 
 \section{Expressions}\label{sec:expressions}
 \Cref{lst:expressions} shows the \cleaninline{expr} class containing the functionality to lift values from the host language to the \gls{MTASK} language (\cleaninline{lit}); perform number and boolean arithmetics; do comparisons; and conditional execution.

-For every common arithmetic operator in the host language, an \gls{MTASK} variant is present, suffixed by a period to not clash with \gls{CLEAN}'s builtin operators.
+For every common boolean and arithmetic operator in the host language, an \gls{MTASK} variant is present, suffixed by a period to not clash with \gls{CLEAN}'s builtin operators.

 
 \begin{lstClean}[caption={The \gls{MTASK} class for expressions},label={lst:expressions}]
 class expr v where
 
 \begin{lstClean}[caption={The \gls{MTASK} class for expressions},label={lst:expressions}]
 class expr v where


@@ -244,7 +299,7 @@ class expr v where
        If :: (v Bool) (v t) (v t) -> v t | type t
 \end{lstClean}
 
        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} that will convert the argument to the respective type similar to casting in \gls{C}.

 
 \begin{lstClean}[caption={Type conversion functions in \gls{MTASK}.}]
 class int  v a :: (v a) -> v Int
 
 \begin{lstClean}[caption={Type conversion functions in \gls{MTASK}.}]
 class int  v a :: (v a) -> v Int


@@ -252,15 +307,13 @@ class real v a :: (v a) -> v Real
 class long v a :: (v a) -> v Long
 \end{lstClean}
 
 class long v a :: (v a) -> v Long
 \end{lstClean}
 

-Finally, values from the host language must be explicitly lifted to the \gls{MTASK} language using the \cleaninline{lit} function.
+Values from the host language must be explicitly lifted to the \gls{MTASK} language using the \cleaninline{lit} function.

 For convenience, there are many lower-cased macro definitions for often used constants such as \cleaninline{true :== lit True}, \cleaninline{false :== lit False}, \etc.
 
 \Cref{lst:example_exprs} shows some examples of these expressions.
 For convenience, there are many lower-cased macro definitions for often used constants such as \cleaninline{true :== lit True}, \cleaninline{false :== lit False}, \etc.
 
 \Cref{lst:example_exprs} shows some examples of these expressions.

+Since they are only expressions, there is no need for a \cleaninline{Main}.

 \cleaninline{e0} defines the literal $42$, \cleaninline{e1} calculates the literal $42.0$ using real numbers.
 \cleaninline{e2} compares \cleaninline{e0} and \cleaninline{e1} as integers and if they are equal it returns the \cleaninline{e2}$/2$ and \cleaninline{e0} otherwise.
 \cleaninline{e0} defines the literal $42$, \cleaninline{e1} calculates the literal $42.0$ using real numbers.
 \cleaninline{e2} compares \cleaninline{e0} and \cleaninline{e1} as integers and if they are equal it returns the \cleaninline{e2}$/2$ and \cleaninline{e0} otherwise.

-\cleaninline{approxEqual} performs an approximate equality---albeit not taking into account all floating point pecularities---and demonstrates that \gls{CLEAN} can be used as a macro language, i.e.\ maximise linguistic reuse~\cite{krishnamurthi_linguistic_2001}.
-\todo{uitzoeken waar dit handig is}
-When calling \cleaninline{approxEqual} in an \gls{MTASK} function, the resulting code is inlined.

 
 \begin{lstClean}[label={lst:example_exprs},caption={Example \gls{MTASK} expressions.}]
 e0 :: v Int | expr v
 
 \begin{lstClean}[label={lst:example_exprs},caption={Example \gls{MTASK} expressions.}]
 e0 :: v Int | expr v


@@ -272,23 +325,31 @@ e1 = lit 38.0 + real (lit 4)
 e2 :: v Int | expr v
 e2 = if' (e0 ==. int e1)
        (int e1 /. lit 2) e0
 e2 :: v Int | expr v
 e2 = if' (e0 ==. int e1)
        (int e1 /. lit 2) e0

+\end{lstClean}
+
+\Gls{MTASK} is shallowly embedded in \gls{CLEAN} and the terms are constructed at runtime.
+This means that \gls{MTASK} programs can also be tailor-made at runtime or constructed using \gls{CLEAN} functions maximising the linguistic reuse \citep{krishnamurthi_linguistic_2001}
+\cleaninline{approxEqual} in \cref{lst:example_macro} performs an approximate equality---albeit not taking into account all floating point pecularities---.
+When calling \cleaninline{approxEqual} in an \gls{MTASK} function, the resulting code is inlined.

 
 

+\begin{lstClean}[label={lst:example_macro},caption={Example linguistic reuse in the \gls{MTASK} language.}]

 approxEqual :: (v Real) (v Real) (v Real) -> v Real | expr v
 approxEqual :: (v Real) (v Real) (v Real) -> v Real | expr v

-approxEqual x y eps = if' (x == y) true
-       ( if' (x > y)
+approxEqual x y eps = if' (x ==. y) true
+       ( if' (x >. y)

                (y -. x < eps)
                (x -. y < eps)
        )
 \end{lstClean}
 
                (y -. x < eps)
                (x -. y < eps)
        )
 \end{lstClean}
 

-\subsection{Data Types}
+\subsection{Data types}

 Most of \gls{CLEAN}'s basic types have been mapped on \gls{MTASK} types.
 However, it can be useful to have access to compound types as well.
 All types in \gls{MTASK} must have a fixed size representation on the stack so sum types are not (yet) supported.
 While it is possible to lift types using the \cleaninline{lit} function, you cannot do anything with the types besides passing them around but they are being produced by some parallel task combinators (see \cref{sssec:combinators_parallel}).
 Most of \gls{CLEAN}'s basic types have been mapped on \gls{MTASK} types.
 However, it can be useful to have access to compound types as well.
 All types in \gls{MTASK} must have a fixed size representation on the stack so sum types are not (yet) supported.
 While it is possible to lift types using the \cleaninline{lit} function, you cannot do anything with the types besides passing them around but they are being produced by some parallel task combinators (see \cref{sssec:combinators_parallel}).

-To be able to use types as first class citizens, constructors and field selectors are required.
+To be able to use types as first class citizens, constructors and field selectors are required (see \cref{chp:first-class_datatypes}).

 \Cref{lst:tuple_exprs} shows the scaffolding for supporting tuples in \gls{MTASK}.
 Besides the constructors and field selectors, there is also a helper function available that transforms a function from a tuple of \gls{MTASK} expressions to an \gls{MTASK} expression of a tuple.
 \Cref{lst:tuple_exprs} shows the scaffolding for supporting tuples in \gls{MTASK}.
 Besides the constructors and field selectors, there is also a helper function available that transforms a function from a tuple of \gls{MTASK} expressions to an \gls{MTASK} expression of a tuple.

+Examples for using tuple can be found in \cref{sec:mtask_functions}.

 
 \begin{lstClean}[label={lst:tuple_exprs},caption={Tuple constructor and field selectors in \gls{MTASK}.}]
 class tupl v where
 
 \begin{lstClean}[label={lst:tuple_exprs},caption={Tuple constructor and field selectors in \gls{MTASK}.}]
 class tupl v where


@@ -299,15 +360,14 @@ class tupl v where
        tupopen f :== \v->f (first v, second v)
 \end{lstClean}
 
        tupopen f :== \v->f (first v, second v)
 \end{lstClean}
 

-\subsection{Functions}
-Adding functions to the language is achieved by one multi-parameter 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}.
-As \gls{MTASK} only supports first-order functions and does not allow partial function application.
-Using a type class of this form, this restriction can be enforced on the type level.
-Instead of providing one instance for all functions, a single instance per function arity is defined.
+\subsection{Functions}\label{sec:mtask_functions}
+Adding functions to the language is achieved by 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} only allows first-order functions and does not allow partial function application.
+This is restricted by using a multi-parameter type class where the first parameter represents the arguments and the second parameter the view.
+By providing a single instance per function arity instead of providing one instance for all functions and using tuples for the arguments this constraint can be enforced.

 Also, \gls{MTASK} only supports top-level functions which is enforced by the \cleaninline{Main} box.
 Also, \gls{MTASK} only supports top-level functions which is enforced by the \cleaninline{Main} box.

-The definition of the type class and the instances for an example interpretation are as follows:
-\todo{uitbreiden}
+The definition of the type class and the instances for an example interpretation (\cleaninline{:: Inter}) are as follows:

 
 \begin{lstClean}[caption={Functions in \gls{MTASK}.}]
 class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u)))
 
 \begin{lstClean}[caption={Functions in \gls{MTASK}.}]
 class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u)))


@@ -315,8 +375,8 @@ class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u)))
 
 instance fun () Inter where ...
 instance fun (Inter a) Inter | type a where ...
 
 instance fun () Inter where ...
 instance fun (Inter a) Inter | type a where ...

-instance fun (Inter a, Inter b) Inter | type a where ...
-instance fun (Inter a, Inter b, Inter c) Inter | type a where ...
+instance fun (Inter a, Inter b) Inter | type a, type b where ...
+instance fun (Inter a, Inter b, Inter c) Inter | type a, ... where ...

 ...
 \end{lstClean}
 
 ...
 \end{lstClean}
 


@@ -358,7 +418,7 @@ swapTuple =
 \end{lstClean}
 % VimTeX: SynIgnore off
 
 \end{lstClean}
 % VimTeX: SynIgnore off
 

-\section{Tasks}\label{sec:top}
+\section{Tasks and task combinators}\label{sec:top}

 \Gls{MTASK}'s task language can be divided into three categories, namely
 \begin{enumerate*}
        \item Basic tasks, in most \gls{TOP} systems, the basic tasks are called editors, modelling the interactivity with the user.
 \Gls{MTASK}'s task language can be divided into three categories, namely
 \begin{enumerate*}
        \item Basic tasks, in most \gls{TOP} systems, the basic tasks are called editors, modelling the interactivity with the user.


@@ -395,7 +455,7 @@ class delay v :: (v n) -> MTask v n | long v n
 \subsubsection{Peripherals}\label{sssec:peripherals}
 For every 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 have such peripherals connected.
 \subsubsection{Peripherals}\label{sssec:peripherals}
 For every 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 have such peripherals connected.

-\todo{Historically, peripheral support has been added \emph{by need}.}
+%\todo{Historically, peripheral support has been added \emph{by need}.}

 
 \Cref{lst:dht,lst:gpio} show the type classes for \glspl{DHT} sensors and \gls{GPIO} access.
 Other peripherals have similar interfaces, they are available in the \cref{sec:aux_peripherals}.
 
 \Cref{lst:dht,lst:gpio} show the type classes for \glspl{DHT} sensors and \gls{GPIO} access.
 Other peripherals have similar interfaces, they are available in the \cref{sec:aux_peripherals}.


@@ -625,6 +685,14 @@ task = declarePin D3 PMInput \d3->
 \chapter{Green computing with \texorpdfstring{\gls{MTASK}}{mTask}}%
 \label{chp:green_computing_mtask}
 
 \chapter{Green computing with \texorpdfstring{\gls{MTASK}}{mTask}}%
 \label{chp:green_computing_mtask}
 

+\section{Green \texorpdfstring{\glsxtrshort{IOT}}{IoT} computing}
+
+\section{Task scheduling}
+\subsection{Language}
+\subsection{Device}
+
+\section{Interrupts}
+

 \chapter{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}%
 \label{chp:integration_with_itask}
 The \gls{MTASK} language is a multi-view \gls{DSL}, i.e.\ there are multiple interpretations possible for a single \gls{MTASK} term.
 \chapter{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}%
 \label{chp:integration_with_itask}
 The \gls{MTASK} language is a multi-view \gls{DSL}, i.e.\ there are multiple interpretations possible for a single \gls{MTASK} term.


@@ -683,46 +751,5 @@ IFL19 paper, bytecode instructieset~\cref{chp:bytecode_instruction_set}
 \section{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}
 IFL18 paper stukken
 
 \section{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}
 IFL18 paper stukken
 

-\chapter{\texorpdfstring{\gls{MTASK}}{mTask} history}
-\section{Generating \texorpdfstring{\gls{C}/\gls{CPP}}{C/C++} code}
-A first throw at a class-based shallowly \gls{EDSL} for microprocessors 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 or even functions.
-Some time later in the 2015 \gls{CEFP} summer school, an extended version was created that allowed the creation of imperative tasks, \glspl{SDS} and the usage of functions~\citep{koopman_type-safe_2019}.
-The name then changed from \gls{ARDSL} to \gls{MTASK}.
-
-\section{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}
-Mart Lubbers extended this in his Master's Thesis by adding integration with \gls{ITASK} and a bytecode compiler to the language~\citep{lubbers_task_2017}.
-\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 Matheus Amazonas Cabral de Andrade that it was possible to build real-life \gls{IOT} systems with this integration~\citep{amazonas_cabral_de_andrade_developing_2018}.
-Moreover, a course on the \gls{MTASK} simulator was provided at the 2018 \gls{CEFP}/\gls{3COWS} winter school in Ko\v{s}ice, Slovakia~\citep{koopman_simulation_2018}.
-
-\section{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, tasks and \glspl{SDS} but still compiled to \gls{CPP} \gls{ARDUINO} code.
-Later the bytecode 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 microprocessor 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} summer school in Budapest, Hungary hosted a course on developing \gls{IOT} applications with \gls{MTASK} as well~\citep{lubbers_writing_2019}.
-
-\section{\texorpdfstring{\gls{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 (the lecture notes are to be written).
-Several students worked on extending \gls{MTASK} with many useful features:
-Erin van der Veen did preliminary work on a green computer analysis, built a simulator and explored the possibilities for adding bounded datatypes~\citep{veen_van_der_mutable_2020}; Michel de Boer investigated the possibilities for secure communication channels~\citep{boer_de_secure_2020}; and Sjoerd Crooijmans added abstractions for low-power operation to \gls{MTASK} such as hardware interrupts and power efficient scheduling~\citep{crooijmans_reducing_2021}.
-Elina Antonova defined a preliminary formal semantics for a subset of \gls{MTASK}~\citep{antonova_MTASK_2022}.
-Moreover, plans for student projects and improvements include exploring integrating \gls{TINYML} into \gls{MTASK}; and adding intermittent computing support to \gls{MTASK}.
-
-In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK} as well.
-
-\section{\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}.
-The collaboration is still ongoing and a journal article is under review comparing four approaches for the edge layer: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK} and \gls{MTASK}.
-Furthermore, 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
-

 \input{subfilepostamble}
 \end{document}
 \input{subfilepostamble}
 \end{document}