\chapter{Prelude}%
\label{chp:introduction}
\begin{chapterabstract}
- This chapter is the introduction of the dissertation and to the thesis.
- It first provides a general introduction to the topics and research venues taken in this document, ending with a reading guide.
- The sections that follow provide background material on the \glsxtrlong{IOT}, \glsxtrlongpl{DSL}, \glsxtrlong{TOP}, \gls{ITASK}, and \gls{MTASK}.
- Finally, it provides a detailed overview of the contributions.
+ This chapter introduces the dissertation and thesis by providing:
+ \begin{itemize}
+ \item a general introduction to the topics and research venues
+ \item a reading guide;
+ \item background material on the \glsxtrlong{IOT}, \glsxtrlongpl{DSL}, \glsxtrlong{TOP}, \gls{ITASK}, and \gls{MTASK};
+ \item and a detailed overview of the scientific contributions.
+ \end{itemize}
\end{chapterabstract}
There are at least 13.4 billion devices connected to the internet at the time of writing\footnote{\url{https://transformainsights.com/research/tam/market}, accessed on: \formatdate{13}{10}{2022}}.
Edge devices are the leafs of the \gls{IOT} systems, they perform the interaction with the physical world.
Typically, these edge devices are powered by microcontrollers.
These miniature computers contain integrated circuits that accomodates a microprocessor designed for use in embedded applications.
-Typically, microcontrollers are therefore tiny in size; have little memory; contain a slow, but energy-efficient processor; and allow for a lot of connectivity for integrating peripherals such as sensors and actuators in order to interact with their surroundings.
-%
-%\begin{figure}[ht]
-% \centering
-% \includegraphics[width=.4\linewidth]{esp}
-% \caption{A typical ESP32 microcontroller prototyping board.}%
-% \label{fig:esp_prototype}
-%\end{figure}
+Typically, microcontrollers are therefore tiny; have little memory; contain a slow, but energy-efficient processor; and allow for a lot of connectivity for integrating peripherals such as sensors and actuators in order to interact with their surroundings.
Unlike the conductor in the orchestra waving their baton to instruct the ensemble of instruments, in the universe of software there is room for little error.
In the traditional setting, an \gls{IOT} engineer has to program each device and their interoperation using different programming paradigms, programming languages, and abstraction levels.
\section{Reading guide}%
\label{lst:reading_guide}
-This work is is structured as a purely functional rhapsody.
+This work is structured as a purely functional rhapsody.
On Wikipedia, a musical rhapsody is defined as follows \citep{wikipedia_contributors_rhapsody_2022}:
\begin{quote}\emph{%
A \emph{rhapsody} in music is a one-movement work that is episodic yet integrated, free-flowing in structure, featuring a range of highly contrasted moods, colour, and tonality.}
\Cref{prt:dsl} is a paper-based---otherwise known as cumulative---episode containing chapters that provide insight in advanced \gls{DSL} embedding techniques for \gls{FP} languages.
The chapters are readable independently.
\Cref{prt:top} is a monograph showing \gls{MTASK}, a \gls{TOP} \gls{DSL} for the \gls{IOT}.
-It introduces \gls{IOT} edge device programming, shows the complete \gls{MTASK} language, provides details on how \gls{MTASK} is integrated with \gls{ITASK}, shows how the byte code compiler is implemented, and concludes with a guide for green computing with \gls{ITASK}.
Hence, the chapters are best read in order.
+It introduces \gls{IOT} edge device programming, shows the complete \gls{MTASK} language, provides details on how \gls{MTASK} is integrated with \gls{ITASK}, shows how the byte code compiler is implemented, with a guide for green computing with \gls{ITASK} and ends with a conclusion and overview of future and related work.
\Cref{prt:tvt} is a single chapter based on a journal article in which traditional tiered \gls{IOT} programming is qualitatively and quantitatively compared to tierless programming using a real-world application.
The chapter is readable independently.
The following sections in this prelude provide background material on the \gls{IOT}, \glspl{DSL}, and \gls{TOP} after which a detailed overview of the contributions is presented.
-Text typeset as \texttt{teletype} represents source code.
-Standalone source code listings are marked by the programming language used, e.g.\ \gls{CLEAN}\footnotemark, \gls{HASKELL}, \gls{CPP}, \etc.
-\footnotetext{\Cref{chp:clean_for_haskell_programmers} contains a guide for \gls{CLEAN} tailored to \gls{HASKELL} programmers.}
\section{\texorpdfstring{\Glsxtrlong{IOT}}{Internet of things}}%
\label{sec:back_iot}
-The \gls{IOT} is growing rapidly and it is changing the way people and machines interact with each other and the world.
+The \gls{IOT} is growing rapidly, and it is changing the way people and machines interact with each other and the world.
While the term \gls{IOT} briefly gained interest around 1999 to describe the communication of \gls{RFID} devices \citep{ashton_internet_1999,ashton_that_2009}, it probably already popped up halfway the eighties in a speech by \citet{peter_t_lewis_speech_1985}:
\begin{quote}
In home automation this layer consists of all the devices hosting sensors and actuators such as smart light bulbs, actuators to open doors, or temperature and humidity sensors.
All layers are connected using the network layer.
-In some applications this is implemented using conventional networking techniques such as WiFi or Ethernet.
+In some applications this is implemented using conventional networking techniques such as Wi-Fi or Ethernet.
However, network technology that is tailored to the needs of the specific interconnection between the two layers have become increasingly popular.
-Examples of this are BLE, LoRa, ZigBee, and LTE-M as a transport for connecting the perception layer to the application layer using \gls{IOT} protocols such as \gls{MQTT}.
+Examples of this are BLE, LoRa, ZigBee, and LTE-M as a communication protocol for connecting the perception layer to the application layer using \gls{IOT} transport protocols such as \gls{MQTT}.
Protocols such as HTTP, AJAX, and WebSocket connecting the presentation layer to the application layer that are designed for the use in web applications.
Across the layers, the devices are a large heterogeneous collection of different platforms, protocols, paradigms, and programming languages often resulting in impedance problems or semantic friction between layers when programming \citep{ireland_classification_2009}.
-Even more so, the perception layer itself is often a heterogeneous collections of microcontrollers in itself, each having their own peculiarities, language of choice, and hardware interfaces.
+Even more so, the perception layer itself is often a heterogeneous collection of microcontrollers in itself, each having their own peculiarities, language of choice, and hardware interfaces.
As edge hardware needs to be cheap, small-scale, and energy efficient, the microcontrollers used to power them do not have a lot of computational power, only a soup\c{c}on of memory, and little communication bandwidth.
-Typically these devices are unable to run a full-fledged general-purpose \gls{OS}.
+Typically, these devices are unable to run a full-fledged general-purpose \gls{OS}.
Rather they employ compiled firmware written in imperative languages that combines all tasks on the device in a single program.
While devices are getting a bit faster, smaller, and cheaper, they keep these properties to an extent, greatly reducing the flexibility for dynamic systems when tasks are created on the fly, executed on demand, or require parallel execution.
-As program memory is mostly flash-based and only lasts a couple of thousand writes before it wears out, it is not suitable for rapid reconfiguring and reprogramming.
+As program memory is mostly flash-based and only lasts a couple of thousands of writes before it wears out, it is not suitable for rapid reconfiguring and reprogramming.
These problems can be mitigated by dynamically sending code to be interpreted to the microcontroller.
With interpretation, a specialized interpreter is flashed in the program memory once it receives the program code to execute at run time.
On the other hand, heterogeneous \glspl{EDSL} are languages that are not executed in the host language.
For example, \citet{elliott_compiling_2003} describe the language Pan, for which the final representation in the host language is a compiler that will, when executed, generate code for a completely different target platform.
In fact, \gls{ITASK} and \gls{MTASK} are embedded \glspl{DSL}.
-\Gls{ITASK} runs in its host language as well so it is a homogeneous \gls{DSL}.
+\Gls{ITASK} runs in its host language as well, so it is a homogeneous \gls{DSL}.
Tasks written using \gls{MTASK} are dynamically compiled to byte code for an edge device and is therefore a heterogeneous \gls{DSL}.
\section{\texorpdfstring{\Glsxtrlong{TOP}}{Task-oriented programming}}%
\label{sec:back_top}
\Gls{TOP} is a recent declarative programming paradigm for modelling interactive systems \citep{plasmeijer_task-oriented_2012}.
-In \gls{TOP} languages, tasks are the basic building blocks and they represent the actual work.
-Instead of dividing problems into \gls{LSOC} \gls{TOP} deals with separation of concerns in a novel way.
+In \gls{TOP} languages, tasks are the basic building blocks.
+They represent the actual work.
+Instead of dividing problems into layers \gls{TOP} deals with separation of concerns in a novel way.
From the data types, utilising various \emph{type-parametrised} concepts, all other aspects are handled automatically (see \cref{fig:tosd}).
This approach to software development is called \gls{TOSD} \citep{wang_maintaining_2018}.
-After describing the layers, the link to the \gls{IOT} architecture is explained.\todo{dit om vast te primen}
\begin{figure}
\centering
\end{figure}
\begin{description}
- \item[\Glsxtrshort{UI} (presentation layer):]
- The \gls{UI} of the system is automatically generated from the representation of the type.
+ \item[\Gls{UI}:]
+ The \gls{UI} of the system is automatically generated from the structural representation of the type.
Though, practical \gls{TOP} systems allow tweaking afterwards to suit the specific needs of the application.
- \item[Tasks (business layer):]
+ \item[Tasks:]
A task is an abstract representation of a piece of work that needs to be done.
It provides an intuitive abstraction over work in the real world.
- Tasks are observable.
- During execution, it is possible to observe a---partial---result and act upon it, e.g.\ by starting new tasks
+ Tasks are observable during execution.
+ It is possible to observe a---partial---result and act upon it, e.g.\ by starting new tasks.
Examples of tasks are filling forms, sending emails, reading sensors or even doing physical tasks.
Just as with real-life tasks, multiple tasks can be combined in various ways such as in parallel or in sequence to form workflows.
Such combination operators are called task combinators.
- \item[\Glsxtrshortpl{SDS} (resource access):]
+ \item[\Glspl{SDS}:]
Tasks mainly communicate using their observable task values.
- However, some collaboration require tasks that are not necessarily related need to share data.
- \Glspl{SDS} fill this gap, they offer a safe and type safe abstraction over any data.
+ However, some collaboration requires tasks that are not necessarily related to share data.
+ \Glspl{SDS} fill this gap, they offer a safe abstraction over any data.
An \gls{SDS} can represent typed data stored in a file, a chunk of memory, a database \etc.
\Glspl{SDS} can also represent external impure data such as the time, random numbers or sensor data.
In many \gls{TOP} langauges, combinators are available to filter, combine, transform, and focus \glspl{SDS}.
- \item[\Glsxtrshort{UOD} (programming language):]
+ \item[\Gls{UOD}:]
The \gls{UOD} is explicitly and separately modelled by the relations that exist in the functions of the host language.
- \todo{uit\-brei\-den}
\end{description}
-This figure differs from the presented \gls{IOT} architecture because they represent separate concepts.
-The \gls{IOT} architecture from \cref{fig:iot} describes an execution architecture wheras the \gls{TOSD} figure describes a softwared development model.
+\Cref{fig:tosd} differs from the presented \gls{IOT} architecture because they represent separate concepts.
+The \gls{IOT} architecture from \cref{fig:iot-layers} describes an execution architecture wheras the \gls{TOSD} figure describes a softwared development model.
E.g.\ from a software development perspective, a task is a task, whether it is executed on a microcontroller, a server or a client.
-Though some concepts can be mapped upon eachother.
+Only once a task is executed, the location of the execution becomes important, but this is taken care of by the system.
+Some concepts from the \gls{TOSD} model can be mapped upon the \gls{IOT} architecture though.
Applying the concepts of \gls{TOSD} to \gls{IOT} systems can be done in two ways.
Firstly, edge devices can be seen as simple resources, thus accessed through \glspl{SDS}.
The second view is that edge devices contain miniature \gls{TOP} systems in itself.
The individual components in the miniature systems, the tasks, the \glspl{SDS}, are, in the eventual execution, connected to the main system.
-\todo{legt dit de link goed genoeg uit?}
+\todo{ik ben niet echt te\-vre\-den met deze \P}
-%\Citet{steenvoorden_tophat_2022} distinguishes two instruments for \gls{TOP}: \gls{TOP} languages and \gls{TOP} engines.
-%The language is the \emph{formal} language for specifying interactive systems.
-%The engine is the software or hardware that executes these specifications as a ready-for-work application.
-%\todo{uit\-brei\-den, ver\-wij\-de\-ren?}
-%
\subsection{\texorpdfstring{\Gls{ITASK}}{ITask}}
-The concept of \gls{TOP} originated from the \gls{ITASK} framework, a declarative interactive systems language and \gls{TOP} engine for defining multi-user distributed web applications implemented as an \gls{EDSL} in the lazy pure \gls{FP} language \gls{CLEAN} \citep{plasmeijer_itasks:_2007,plasmeijer_task-oriented_2012}.
+The concept of \gls{TOP} originated from the \gls{ITASK} framework, a declarative language and \gls{TOP} engine for defining interactive multi-user distributed web applications.
+\Gls{ITASK} is implemented as an \gls{EDSL} in the lazy pure \gls{FP} language \gls{CLEAN} \citep{plasmeijer_itasks:_2007,plasmeijer_task-oriented_2012}.
From the structural properties of the data types, the entire user interface is automatically generated.
-Browsers are powering \gls{ITASK}'s perception layer.
+Browsers are powering \gls{ITASK}'s presentation layer.
The framework is built on top of standard web techniques such as JavaScript, HTML, and {CSS}.
\Gls{ITASK} code running in the browser relies on an interpreter that operates on \gls{CLEAN}'s intermediate language \gls{ABC} \citep{staps_lazy_2019}.
Tasks in \gls{ITASK} have either \emph{no value}, an \emph{unstable} or a \emph{stable} task value.
+For example, an editor for filling in a form initially has no value.
+Once the user entered a complete value, its value becomes an unstable value, it can still be changed or even reverted to no value by emptying the editor again.
+Only when for example a continue button is pressed, a task becomes stable, fixing its value.
The allowed task value transitions are shown in \cref{fig:taskvalue}.
-\begin{figure}
+\begin{figure}[ht]
\centering
\includestandalone{taskvalue}
\caption{Transition diagram for task values in \gls{ITASK}.}%
\end{figure}
As an example, \cref{lst:todo,fig:todo} show the code and \gls{UI} for an interactive to-do list application.
-The user can modify a shared to-do list through an editor directly or using some of the predefined actions.
+The user can modify a shared to-do list through an editor directly or using some predefined actions.
Furthermore, in parallel, the length of the list is shown to demonstrate \glspl{SDS}.
From the data type definitions (\cref{lst:todo_dt}), using generic programming (\cref{lst:todo_derive}), the \glspl{UI} for the data types are automatically generated.
-Then, using the parallel task combinator (\cleaninline{-\|\|}) that uses the left-hand side's result the task for updating the todos (\cref{lst:todo_update}) and the task for viewing the length are combined (\cref{lst:todo_length}).
-Both tasks operate on the todo \gls{SDS} (\cref{lst:todo_sds}).
-The task for updating the todo list is just an editor (\cref{lst:todo_editor}) combined using a step combinator (\crefrange{lst:todo_contfro}{lst:todo_contto}).
+Then, using the parallel task combinator (\cleaninline{-\|\|}) that uses the left-hand side's result the task for updating the to-dos (\cref{lst:todo_update}) and the task for viewing the length are combined (\cref{lst:todo_length}).
+Both tasks operate on the to-do \gls{SDS} (\cref{lst:todo_sds}).
+The task for updating the to-do list is just an editor (\cref{lst:todo_editor}) combined using a step combinator (\crefrange{lst:todo_contfro}{lst:todo_contto}).
The actions either change the value, sorting or clearing it, or terminates the task by returning the current value of the \gls{SDS}.
Special combinators (e.g.\ \cleaninline{@>>} at \cref{lst:todo_ui}) are used to tweak the \gls{UI} to display informative labels.
\begin{figure}
\centering
\includegraphics[width=.75\linewidth]{todo0g}
- \caption{The \gls{UI} for the shared to-do list \gls{ITASK}.}%
+ \caption{The \gls{UI} for the shared to-do list in \gls{ITASK}.}%
\label{fig:todo}
\end{figure}
-\cleaninputlisting[firstline=6,lastline=22,tabsize=3,numbers=left,caption={The code for a shared to-do list in \gls{ITASK}.},label={lst:todo}]{lst/sharedlist.icl}
+\cleaninputlisting[float=,firstline=6,lastline=22,tabsize=3,numbers=left,caption={The code for the shared to-do list in \gls{ITASK}\footnotemark.},label={lst:todo}]{lst/sharedlist.icl}
+\footnotetext{\Cref{chp:clean_for_haskell_programmers} contains a guide for \gls{CLEAN} tailored to \gls{HASKELL} programmers.}
\subsection{\texorpdfstring{\Gls{MTASK}}{MTask}}
\Gls{ITASK} seems an obvious candidate at first glance for extending \gls{TOP} to \gls{IOT} edge devices.
From an \gls{MTASK} task constructed at run time, a compact binary representation of the work that needs to be done is compiled.
This byte code is then sent to a device that running the \gls{MTASK} \gls{RTS}.
This feather-light domain-specific \gls{OS} is written in portable \gls{C} with a minimal device specific interface and functions as a \gls{TOP} engine.
-\Gls{MTASK} is seamlessly integrated with \gls{ITASK}: \gls{MTASK} tasks are integrated in such a way that they function as \gls{ITASK} tasks, and \glspl{SDS} in on the device can tether an \gls{ITASK} \gls{SDS}.
+\Gls{MTASK} is seamlessly integrated with \gls{ITASK}: \gls{MTASK} tasks are integrated in such a way that they function as \gls{ITASK} tasks, and \glspl{SDS} on the device can tether an \gls{ITASK} \gls{SDS}.
Using \gls{MTASK}, the programmer can define all layers of an \gls{IOT} system as a single declarative specification.
\Cref{lst:intro_blink,fig:intro_blink} shows the \gls{ITASK} part of the code and a screenshot of an interactive \imtask{} application for blinking \pgls{LED} on the microcontroller every dynamically changeable interval.
Once connected, the \cleaninline{intBlink} task is sent to the device (\cref{lst:intro_liftmtask}) and, in parallel, an editor is shown that updates the value of the interval \gls{SDS} (\cref{lst:intro_editor}).
To allow ending the task, the \gls{ITASK} task ends with a sequential operation that returns a constant value when the button is pressed, making the task stable.
-\cleaninputlisting[firstline=10,lastline=18,numbers=left,caption={\Imtask{} interactive blinking.},label={lst:intro_blink}]{lst/blink.icl}
+\cleaninputlisting[firstline=10,lastline=18,numbers=left,caption={The \gls{ITASK} code for the interactive blinking application.},label={lst:intro_blink}]{lst/blink.icl}
\begin{figure}
\centering
\begin{subfigure}{.5\textwidth}
\centering
- \includegraphics[width=.975\linewidth]{blink1g}
+ \includegraphics[width=.9\linewidth]{blink1g}
\caption{Device selection.}
\end{subfigure}%
\begin{subfigure}{.5\textwidth}
\centering
- \includegraphics[width=.975\linewidth]{blink2g}
+ \includegraphics[width=.9\linewidth]{blink2g}
\caption{Changing the interval.}
\end{subfigure}
- \caption{Screenshots for the interactive blink application.}%
+ \caption{The \gls{UI} for the interactive blink application in \gls{MTASK}.}%
\label{fig:intro_blink}
\end{figure}
\begin{lstClean}[numbers=left,belowskip=0pt]
intBlink :: (Shared sds Int) -> Main (MTask v Int) | mtask v & ...\end{lstClean}
-\cleaninputlisting[aboveskip=0pt,firstnumber=3,firstline=22,numbers=left,caption={\Gls{MTASK} part of the interactive blinking application.},label={lst:intro_blink_mtask}]{lst/blink.icl}
+\cleaninputlisting[aboveskip=0pt,firstnumber=3,firstline=22,numbers=left,caption={The \gls{MTASK} code for the interactive blinking application.},label={lst:intro_blink_mtask}]{lst/blink.icl}
\subsection{Other \texorpdfstring{\glsxtrshort{TOP}}{TOP} languages}
While \gls{ITASK} conceived \gls{TOP}, it is not the only \gls{TOP} system.
Finally there are \gls{TOP} languages with strong academic foundations.
\Gls{TOPHAT} is a fully formally specified \gls{TOP} language designed to capture the essence of \gls{TOP} formally \citep{steenvoorden_tophat_2019}.
Such a formal specification allows for symbolic execution, hint generation, but also the translation to \gls{ITASK} for actually performing the work \citep{steenvoorden_tophat_2022}.
+\Citeauthor{steenvoorden_tophat_2022} distinguishes two instruments for \gls{TOP}: \gls{TOP} languages and \gls{TOP} engines.
+The language is the \emph{formal} language for specifying interactive systems.
+The engine is the software or hardware that executes these specifications as a ready-for-work application.
\section{Contributions}%
\label{sec:contributions}
\subsection{\Fullref{prt:dsl}}
The \gls{MTASK} system is a heterogeneous \gls{EDSL} and during the development of it, several novel basal techniques for embedding \glspl{DSL} in \gls{FP} languages have been found.
-This episode is paper based and contains the following papers:
+This paper-based episode contains the following papers:
\begin{enumerate}
\item \emph{Deep Embedding with Class} \citep{lubbers_deep_2022} is the basis for \cref{chp:classy_deep_embedding}.
It shows a novel deep embedding technique for \glspl{DSL} where the resulting language is extendible both in constructs and in interpretation just using type classes and existential data types.
Furthermore, I co-authored another paper that is worth mentioning but is not part of the \gls{MTASK} system yet and hence not part of the dissertation.
\begin{enumerate}[resume]
- \item \emph{Strongly-Typed Multi-View Stack-Based Computations} \citep{koopman_strongly-typed_2022} shows how to create type-safe \glspl{EDSL} representing stack-based computations.
+ \item \emph{Strongly-Typed Multi-View Stack-Based Computations} \citep{koopman_strongly-typed_2022}\label{enum:stack-based} shows how to create type-safe \glspl{EDSL} representing stack-based computations.
Instead of encoding the arguments to a function as arguments in the host language, stack-based approaches use a run time stack that contains the arguments.
By encoding the required contents of the stack in the types, such systems can be made type safe.
\end{enumerate}
\paragraph{Contribution:}
-The research in these papers and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer in which we discussed and refined the ideas for paper~\ref{enum:first-class}.
+The papers of which I am first author are solely written by me, there were weekly meetings with co-authors in which we discussed and refined the ideas.
\subsection{\Fullref{prt:top}}
This episode is a monograph that shows the design, properties, implementation and usage of the \gls{MTASK} system and \gls{TOP} for the \gls{IOT}.
\begin{enumerate}[resume]
\item \emph{A Task-Based \glsxtrshort{DSL} for Microcomputers} \citep{koopman_task-based_2018}
is the initial \gls{TOP}\slash{}\gls{MTASK} paper.
- It provides an overview of the initial \gls{TOP} \gls{MTASK} language and shows first versions of some of the interpretations.
+ It provides an overview of the initial \gls{TOP} \gls{MTASK} language and shows first versions of some interpretations.
\item \emph{Task Oriented Programming for the Internet of Things} \citep{lubbers_task_2018}\footnotetext{This work is an extension of my Master's thesis \citep{lubbers_task_2017}.}
shows how a simple imperative variant of \gls{MTASK} was integrated with \gls{ITASK}.
While the language was a lot different from later versions, the integration mechanism is still used in \gls{MTASK} today.
% \paragraph{Contribution}
% The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer.
\item \emph{Simulation of a Task-Based Embedded Domain Specific Language for the Internet of Things} \citep{koopman_simulation_2018}\footnotemark[\value{footnote}]
- are the revised lecture notes are from 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, January 22--26, 2018.
+ are the revised lecture notes for 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, January 22--26, 2018.
% \paragraph{Contribution}
% Pieter Koopman wrote and taught it, I helped with the software and research.
\item \emph{Writing Internet of Things Applications with Task Oriented Programming} \citep{lubbers_writing_2019}\footnotemark[\value{footnote}]
--- /dev/null
+\documentclass[../thesis.tex]{subfiles}
+
+\input{subfilepreamble}
+
+\begin{document}
+\input{subfileprefix}
+\chapter{Finale}%
+\label{chp:finale}
+\begin{chapterabstract}
+ This chapter wraps up the monograph by:
+ \begin{itemize}
+ \item providing a conclusion;
+ \item and an overview of the related work;
+ \end{itemize}
+\end{chapterabstract}
+
+\section{Finale}
+
+\section{Related work}
+The novelties of the \gls{MTASK} system can be compared to existing systems in several categories.
+It is an interpreted (\cref{sec:related_int}) \gls{TOP} (\cref{sec:related_top}) \gls{DSL} (\cref{sec:related_dsl}) that may seem similar at first glance to \gls{FRP} (\cref{sec:related_frp}), it is implemented in a functional language (\cref{sec:related_fp}) and due to the execution semantics, multitasking is automatically supported (\cref{sec:related_multi}).
+\todo{uit\-brei\-den waar mo\-ge\-lijk}
+
+\subsection{Interpretation}\label{sec:related_int}
+There are a myriad of interpreted programming languages available for some of the bigger devices.
+For example, for the popular ESP8266 chip there are ports of \gls{MICROPYTHON}, LUA, Basic, JavaScript and Lisp.
+All of these languages, except the Lisp dialect uLisp (see \cref{sec:related_fp}), are imperative and do not support multithreading out of the box.
+They lay pretty hefty constraints on the memory and as a result do not work on smaller microcontrollers.
+A interpretation solution for the tiniest devices is Firmata, a protocol for remotely controlling the microcontroller and using a server as the interpreter host \citep{steiner_firmata:_2009}.
+\citet{grebe_haskino:_2016} wrapped this in a remote monad for integration with \gls{HASKELL} that allowed imperative code to be interpreted on the microprocessors.
+Later this system was extended to support multithreading as well, stepping away from Firmata as the basis and using their own \gls{RTS} \citep{grebe_threading_2019}.
+It differs from our approach because continuation points need to be defined by hand there is no automatic safe data communication.
+
+\subsubsection{\texorpdfstring{\Glsxtrlongpl{DSL}}{DSLs} for microcontrollers}\label{sec:related_dsl}
+Many \glspl{DSL} provide higher-level programming abstractions for microcontrollers, for example providing strong typing or memory safety.
+For example Copilot \citep{hess_arduino-copilot_2020} and Ivory \citep{elliott_guilt_2015} are imperative \glspl{DSL} embedded in a functional language that compile to \ccpp{}.
+
+\subsection{\texorpdfstring{\Glsxtrlong{FP}}{Functional programming}}\label{sec:related_fp}
+\Citet{haenisch_case_2016} showed that there are major benefits to using functional languages for \gls{IOT} applications.
+They showed that using function languages increased the security and maintainability of the applications.
+Traditional implementations of general purpose functional languages have high memory requirements rendering them unusable for tiny computers.
+There have been many efforts to create a general purpose functional language that does fit in small memory environments, albeit with some concessions.
+For example, there has been a history of creating tiny Scheme implementations for specific microcontrollers.
+It started with BIT \citep{dube_bit:_2000} that only required \qty{64}{\kibi\byte} of memory, followed by {PICBIT} \citep{feeley_picbit:_2003} and {PICOBIT} \citep{st-amour_picobit:_2009} that lowered the memory requirements even more.
+More recently, \citep{suchocki_microscheme:_2015} created Microscheme, a functional language targeting \gls{ARDUINO} compatible microcontrollers.
+The {*BIT} languages all compile to assembly while Microscheme compiles to \gls{CPP}, heavily supported by \gls{CPP} lambdas available even on \gls{ARDUINO} AVR targets.
+An interpreted Lisp implementation called uLisp also exists that runs on microcontrollers with as small as the \gls{ARDUINO} {UNO} \citep{johnson-davies_lisp_2020}.
+
+\subsection{\texorpdfstring{\Glsxtrlong{FRP}}{Functional reactive programming}}\label{sec:related_frp}
+The \gls{TOP} paradigm is often compared to \gls{FRP} and while they appear to be similar---they both process events---, in fact they are very different.
+\Gls{FRP} was introduced by \citet{elliott_functional_1997}.
+The paradigm strives to make modelling systems safer, more efficient, composable.
+The core concepts are behaviours and events.
+A behaviour is a value that varies over time.
+Events are happenings in the real world and can trigger behaviours.
+Events and behaviours may be combined using combinators.
+\Gls{TOP} allows for more complex collaboration patterns than \gls{FRP} \citep{wang_maintaining_2018}, and in consequence is unable to provide the strong guarantees on memory usage available in a restricted variant of \gls{FRP} such as arrowized \gls{FRP} \citep{nilsson_functional_2002}.
+
+The way \gls{FRP}, and for that matter \gls{TOP}, systems are programmed stays close to the design when the domain matches suits the paradigm.
+The \gls{IOT} domain seems to suit this style of programming very well in just the device layer\footnote{While a bit out of scope, it deserves mention that for \gls{SN}, \gls{FRP} and stream based approaches are popular as well \citep{sugihara_programming_2008}.} but also for entire \gls{IOT} systems.
+
+For example, Potato is an \gls{FRP} language for building entire \gls{IOT} systems using powerful devices such as the Raspberry Pi leveraging the Erlang \gls{VM} \citep{troyer_building_2018}.
+It requires client devices to be able to run the Erlang \gls{VM} which makes it unsuitable for low memory environments.
+
+The emfrp language compiles a \gls{FRP} specification for a microcontroller to \gls{C} code \citep{sawada_emfrp:_2016}.
+The \gls{IO} part, the bodies of some functions, still need to be implemented.
+These \gls{IO} functions can then be used as signals and combined as in any \gls{FRP} language.
+Due to the compilation to \gls{C} it is possible to run emfrp programs on tiny computers.
+However, the tasks are not interpreted and there is no communication with a server.
+
+Other examples are mfrp \citep{sawada_emfrp:_2016}, CFRP \citep{suzuki_cfrp_2017}, XFRP \citep{10.1145/3281366.3281370}, Juniper \citep{helbling_juniper:_2016}, Hailstorm \citep{sarkar_hailstorm_2020}, Haski \citep{valliappan_towards_2020}, arduino-copilot~\cite{hess_arduino-copilot_2020}.
+
+\subsection{\texorpdfstring{\Glsxtrlong{TOP}}{Task-oriented programming}}\label{sec:related_top}
+\Gls{TOP} as a paradigm with has been proven to be effective for implementing distributed, multi-user applications in many domains.
+Examples are conference management \citep{plasmeijer_conference_2006}, coastal protection \citep{lijnse_capturing_2011}, incident coordination \citep{lijnse_incidone:_2012}, crisis management \citep{jansen_towards_2010} and telemedicine \citep{van_der_heijden_managing_2011}.
+In general, \gls{TOP} results in a higher maintainability, a high separation of concerns and more effective handling of interruptions of workflow.
+\Gls{IOT} applications contain a distributed and multi-user component, but the software on the device is mostly follows multiple loosely dependent workflows.
+The only other \gls{TOP} language for embedded systems is $\mu$Tasks \citep{piers_task-oriented_2016}.
+It is a non-distributed \gls{TOP} \gls{EDSL} hosted in \gls{HASKELL} designed for embedded systems such as payment terminals.
+They showed that applications tend to be able to cope well with interruptions and be more maintainable.
+However, the hardware requirements for running the standard \gls{HASKELL} system are high.
+
+\subsection{Multi tasking}\label{sec:related_multi}
+
+\input{subfilepostamble}
+\end{document}
repositories / phd-thesis.git / commitdiff