\begin{document}
%\includepdf[landscape,booklet,pages={1-18}]{thesis.pdf}%chktex 29 chktex 8
-\includepdf[landscape,booklet,pages={1-}]{top/4iot.pdf}%chktex 29 chktex 8
+%\includepdf[landscape,booklet,pages={1-}]{top/4iot.pdf}%chktex 29 chktex 8
+\includepdf[pages={210}]{thesis.pdf}%chktex 29 chktex 8
\end{document}
First of all I would like to thank Rinus Plasmeijer, Pieter Koopman, and Jan Martin Jansen for the supervision, I learned a lot from you, not only regarding academia but in many other aspects of life as well.
The BEST people, Adrian Ramsingh, Jeremy Singer, and Phil Trinder for the fruitful collaboration, and the memorable trip to Glasgow.
-The CEFP/SusTrainable group, for offering a platform for the various summer schools I had the opportunity to teach; and not to mention the countless meetings, dinners, and drinks we had.
+The \glsxtrshort{CEFP}/SusTrainable group, for offering a platform for the various summer schools I had the opportunity to teach; and not to mention the countless meetings, dinners, and drinks we had.
The Royal Dutch Navy, in particular Teun de Groot and Ton van Heusden, for trusting me by funding the project.
All the colleagues and others that I had the privilege of sharing an office with, meeting in conferences, interact with in the department, or work with in some other way:
Arjan Oortgiese,
I give special thanks to my mentors who never stopped having faith me:
Jos Baack, Francisco Torreira, Franc Grootjen, Louis Vuurpijl, and Larry Caruthers.
-And of course my friends and acquaintances that supported me throughout the procses.
+And of course my friends and acquaintances that supported me throughout the process.
Pieter Wolfert and Anouk Neerincx;
Chris Kamphuis and Maudy Bijen;
Koen Dercksen and Michelle Everard;
Annerieke Wessels;
Camil Staps.
-Finally I want to thank the ones closest to me.
\selectlanguage{dutch}
+Als laatste wil ik diegene bedanken die het dichtst bij mij staan.
Elvira, Rosalie en Liselotte voor hun tomeloze geduld en ondersteuning wanneer dat nodig was.
Mijn ouders in het bijzonder voor hun liefde en vertrouwen.
-Mijn Oma, broers, schoonfamilie en alle andere familieleden die op wat voor manier dan ook bijgedragen hebben.
+Mijn oma, broers, schoonfamilie en alle andere familieleden die op wat voor manier dan ook bijgedragen hebben.
\selectlanguage{british}
%\end{center}
%\begin{center}
\noindent%
\todo{lang\-uage de\-pen\-dent ac\-ro\-nyms?}
-We zien een exponentiële groei in het aantal computers om ons heen.
-De systemen waarvan ze onderdeel zijn worden alras complexer.
-Veel van deze computers zijn zogeheten \emph{rand apparaten} die een onderdeel uitmaken van \gls{IOT} systemen.
-Deze rand apparaten in het orkest van computers zijn de oren en ogen van het systeem, ze hebben interactie met de wereld.
-Meestal worden deze gespecialiseerde computers door microcontrollers en hebben ze slechts weinig geheugen, kleine processoren en langzame communicatie.
-Daarentegen zijn ze speciaal ontworpen voor ingebedde systemen waardoor ze goedkoop zijn, weinig energie verbruiken en veel mogelijk hebben tot het verbinden van allerhande sensoren en actuatoren.
-\Gls{IOT} systemen opereren dikwijls dynamisch, interactief en gedistribueerd.
-Verder zijn ze ondersteunen ze de samenwerking van meerdere gebruikers en en voeren ze meerdere taken tegelijkertijd uit.
-In dit orkest van computers hebben alle instrumenten grote onderlinge verschillen als het gaat om de eigenschappen van de hard- en software resulterende in zogeheten \emph{semantische wrijving}.
-Dit maakt dat het programmeren van deze systemen een klassiek moeilijk probleem is.
-
-\Gls{TOP} is a declarative programming paradigm with roots in functional programming that allows high-level interactive collaborative workflows to be specified for the work that needs to be done.
-From this specification, a ready-for-work computer program is generated supporting the user in actually performing the work.
-The main building blocks of \gls{TOP} programs are tasks, an abstract representation of work that needs to be done.
-During execution, the current value of a task is observable and other tasks can act upon it.
-Furthermore, tasks can be combined and transformed to create compound tasks, allowing the modelling of many collaboration patterns.
-Tasks running on edge devices can intuitively be built from the same \gls{TOP} concepts as the interactive collaborative applications \gls{TOP} was originally designed for, albeit with domain-specific primitives such as sensor and actuator access.
-
-This dissertation shows how to orchestrate complete \gls{IOT} systems using \gls{TOP}.
-First I present advanced \gls{DSL} embedding techniques that make the creation of a \gls{DSL} such as \gls{MTASK} possible.
-Then I show \gls{MTASK}, a \gls{TOP} \gls{DSL} for \gls{IOT} edge devices.
-\Gls{MTASK} is embedded in \gls{ITASK}, a general-purpose \gls{TOP} language mostly used to program interactive web applications.
-All aspects of the \gls{MTASK} system are show: the design, implementation, integration with \gls{ITASK}, and a detailed overview of the green computing facilities.
-Using \gls{MTASK} in conjunction with \gls{ITASK}, entire \gls{IOT} systems can be programmed from a single source, in a single paradigm, and using a single high abstraction level.
-Finally, this tierless approach to \gls{IOT} systems is qualitatively and quantitatively compared to traditional tiered approaches.
Dit is een samenvatting van 350--400 woorden.
%\end{center}
\begin{document}
\input{subfileprefixsmall}
-\chapter*{Summary}%
-\label{chp:summary}
+\chapter{Summary}%
+\label{chp:summary}%
%\begin{center}
-\noindent%
-The amount of computers around us is growing exponentially.
+%\noindent%
+The number of computers around us is growing exponentially.
With it, the systems in which they operate are becoming increasingly complex.
-Many of these computers are so called \emph{edge devices}, operating in \gls{IOT} systems.
-Within these orchestras of computers, they perform the role of interacting with the outside world.
-These specialised computers are often powered by microcontrollers and therefore have little memory, small processors, and slow communication.
-On the other hand, they are designed for embedded systems and hence cheap, tiny, energy efficient, and is easily equipped with various sensors and actuators.
-Not only are \gls{IOT} systems dynamic, interactive, distributed, collaborative, multi-user, and multitasking.
-Also, the orchestra of computers has vastly different hardware and software characteristics, causing semantic friction, making programming such systems classically complex.
+Many of these computers are so called \emph{edge devices}, operating in \glsxtrfull{IOT} systems.
+Within these orchestras of computers, they perform the role of interacting with the outside world using sensors and actuators.
+These specialised computers designed for embedded applications are often powered by microcontrollers and therefore have little memory, unhurried processors, no \glsxtrshort{OS} and slow communication.
+On the other hand, they are cheap, tiny, and energy efficient.
+Programming \glsxtrshort{IOT} systems is complex because they are dynamic, interactive, distributed, collaborative, multi-user, multi-tiered, and multitasking.
+This is impeded even more due to the computers in each tier having vastly different hardware and software characteristics; using different programming languages; and operating in different abstraction levels, causing semantic friction.
-\Gls{TOP} is a declarative programming paradigm with roots in functional programming that allows high-level interactive collaborative workflows to be specified for the work that needs to be done.
-From this specification, a ready-for-work computer program is generated supporting the user in actually performing the work.
-The main building blocks of \gls{TOP} programs are tasks, an abstract representation of work that needs to be done.
+\Glsxtrfull{TOP} is a declarative programming paradigm %with roots in functional programming
+that allows interactive collaborative workflows to be specified for the work that needs to be done.
+From this declarative specification, a ready-for-work computer program the interoperation is generated.
+The main building blocks of \glsxtrshort{TOP} programs are tasks, an abstract representation of work that needs to be done.
During execution, the current value of a task is observable and other tasks can act upon it.
-Furthermore, tasks can be combined and transformed to create compound tasks, allowing the modelling of many collaboration patterns.
-Tasks running on edge devices can intuitively be built from the same \gls{TOP} concepts as the interactive collaborative applications \gls{TOP} was originally designed for, albeit with domain-specific primitives such as sensor and actuator access.
+Tasks are combined and transformed to create compound tasks, allowing the modelling of many collaboration patterns.
+Tasks running on edge devices can intuitively be built from the same \glsxtrshort{TOP} concepts as the interactive collaborative applications \glsxtrshort{TOP} was originally designed for, albeit with domain-specific primitives such as sensor and actuator access.
+However, it is not straightforward to run \glsxtrshort{TOP} systems on edge devices due to the severe hardware constraints.
-This dissertation shows how to orchestrate complete \gls{IOT} systems using \gls{TOP}.
-First I present advanced \gls{DSL} embedding techniques that make the creation of a \gls{DSL} such as \gls{MTASK} possible.
-Then I show \gls{MTASK}, a \gls{TOP} \gls{DSL} for \gls{IOT} edge devices.
-\Gls{MTASK} is embedded in \gls{ITASK}, a general-purpose \gls{TOP} language mostly used to program interactive web applications.
-All aspects of the \gls{MTASK} system are show: the design, implementation, integration with \gls{ITASK}, and a detailed overview of the green computing facilities.
-Using \gls{MTASK} in conjunction with \gls{ITASK}, entire \gls{IOT} systems can be programmed from a single source, in a single paradigm, and using a single high abstraction level.
-Finally, this tierless approach to \gls{IOT} systems is qualitatively and quantitatively compared to traditional tiered approaches.
+In this dissertation I show how to orchestrate complete \glsxtrshort{IOT} systems using \glsxtrshort{TOP}.
+First, I present advanced \glsxtrfull{DSL} embedding techniques that make the creation of a \glsxtrshort{DSL} such as \gls{MTASK} possible.
+Then \glsxtrshort{MTASK} is shown, a \glsxtrshort{TOP} \glsxtrshort{DSL} for \glsxtrshort{IOT} edge devices.
+\gls{MTASK} is embedded in \gls{ITASK}, a general-purpose \glsxtrshort{TOP} language mostly used to program interactive web applications.
+All aspects of the \gls{MTASK} system are shown: the design of the language, details on the implementation, the integration with \gls{ITASK}, and a detailed overview of the green computing facilities.
+Using \gls{MTASK} in conjunction with \gls{ITASK}, entire \glsxtrshort{IOT} systems are programmed from a single source, paradigm, high abstraction level, and type system.
+Consequently, many problems such as semantic friction, maintainability, robustness, interoperation safety are mitigated.
%This is a summary of 350--400 words.
%\end{center}
This chapter concludes the dissertation and reflects on the work.
\end{chapterabstract}
\section{Reflections}
-Programming \gls{IOT} systems is classically complex.
-The heterogeneous collection of computers requires an multi-user multi-tasking interactive distributed environment supporting multi-tasking on all levels.
-\Gls{TOP} has shown to provide a programming paradigm that allows the declarative specification of exactly such systems.
-However, edge devices are often to computationally restricted to be able to run traditional \gls{TOP} systems.
-This thesis made an effort to shed light on orchestrating complete \gls{IOT} system using \gls{TOP}, specifically filling in the knowledge gap for edge devices.
+Programming \gls{IOT} systems is classically complex.\todo{chap\-ter\-ab\-stract weg?}
+Traditionally, on each layer of the system, different computers, hardware architectures, programming languages, programming paradigms, and abstraction levels are required.
+All these factiors generating a lot of semantic friction.
+Furthermore, \gls{IOT} systems are very convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative.
+\Gls{TOP} has shown to provide a suitable programming paradigm that allows the declarative specification of exactly such systems.
+However, edge devices are often too computationally restricted to be able to run traditional \gls{TOP} systems.
+This thesis sheds light on orchestrating complete \gls{IOT} system using \gls{TOP}, specifically filling in the knowledge gap for edge devices in three episodes.
\Cref{prt:dsl} presented two novel techniques for embedding \glspl{DSL} in \gls{FP} languages.
-The novel embedding classy deep embedding technique allows extension of a deeply embedded \gls{DSL} both in language constructs and in language interpretations.
+The novel classy deep embedding technique allows extension of a deeply embedded \gls{DSL} both in language constructs and in language interpretations.
Furthermore, by using the structural information available at compile time, a lot of the boilerplate required to develop an interoperating \gls{IOT} system can be automatically and hence safely generated.
\Cref{prt:top} gave an overview of the \gls{MTASK} system, it's design, integration with \gls{ITASK}, implementation, and green computing facilities.
The \gls{MTASK} \gls{DSL} is set up in such a way that it is possible to create high-level \gls{TOP} programs performing common \gls{IOT} edge devices work dynamically and send them to the edge device at run time.
\Cref{prt:tvt} qualitatively and quantitatively compared traditional \gls{IOT} system programming, tiered programming, to the tierless programming.
-We have shown that programming such complex systems using a tierless approach such as using \gls{MTASK} or even \gls{ITASK} reduces the development effort and making developing these systems.
+We have shown that programming such complex systems using a tierless approach such as using \gls{MTASK} or even \gls{ITASK} reduces the development effort required to making these systems.
Concretely, it results in fewer \gls{SLOC}, files, programming languages and programming paradigms.
However, it is not a silver bullet.
opt_g (NotLoop_g e) = NotLoop_g (opt_g e)
\end{lstHaskellLhstex}
-\section{Conclusion}%
-
-Classy deep embedding is a novel organically grown embedding technique that alleviates deep embedding from the extensibility problem in most cases.
-
-By abstracting the semantics functions to type classes they become overloaded in the language constructs.
-Thus, making it possible to add new language constructs in a separate type.
-These extensions are brought together in a special extension constructor residing in the main data type.
-This extension case is overloaded by the language construct using a data type containing the class dictionary.
-As a result, orthogonal extension is possible for language constructs and semantics using only little syntactic overhead or type annotations.
-The basic technique only requires---well established through history and relatively standard---existential data types.
-However, if needed, the technique generalises to \glspl{GADT} as well, adding rank-2 types to the list of type system requirements as well.
-Finally, the abstract syntax tree remains observable which makes it suitable for intensional analyses, albeit using occasional dynamic typing for truly cross-extensional transformations.
-
-Defining reusable expressions overloaded in semantics or using multiple semantics on a single expression requires some boilerplate still, getting around this remains future work.
-\Cref{sec:classy_reprise} shows how the boilerplate can be minimised using advanced type system extensions.
-
\section{Related work}%
\label{sec:cde:related}
Hybrid approaches between deep and shallow embedding exist as well.
For example, \citet{svenningsson_combining_2013} show that by expressing the deeply embedded language in a shallowly embedded core language, extensions can be made orthogonally as well.
-This paper differs from those approaches in the sense that it does not require a core language in which all extensions need to be expressible.
+Classy deep embedding differs from the hybrid approaches in the sense that it does not require the language extensions to be expressible in the core language.
\subsection{Comparison}
-No \gls{DSL} embedding technique is the silver bullet.
+No \gls{DSL} embedding technique is the silver bullet, there is no way of perfectly satisfying all requiremens programmers have.
\Citet{sun_compositional_2022} provided a thorough comparison of embedding techniques including more axes than just the two stated in the expression problem.
\Cref{tbl:dsl_comparison_brief} shows a variant of their comparison table.
-The first two rows describe the two axes of the original expression problem and the third row describes theadded axis of modular dependency handling as stated by \citeauthor{sun_compositional_2022}.
+The first two rows describe the two axes of the original expression problem and the third row describes the added axis of modular dependency handling as stated by \citeauthor{sun_compositional_2022}.
The \emph{poly.} style of embedding---including tagless-final---falls short of this requirement.
Intensional analysis is an umbrella term for pattern matching and transformations.
In shallow embedding, intensional analysis is more complex and requires stateful views describing context but it is possible to implement though.
-Simple type system describes the whether it is possible to encode this embedding technique with many type system extensions.
+Simple type system describes the whether it is possible to encode this embedding technique without many type system extensions.
In classy deep embedding, there is either a bit more scaffolding and boilerplate required or advanced type system extensions need to be used.
Little boilerplate denotes the amount of scaffolding and boilerplate required.
& \CIRCLE{}\\
Intensional analysis & \LEFTcircle{}\tnote{2} & \CIRCLE{} & \CIRCLE{}
& \LEFTcircle{}\tnote{2} & \LEFTcircle{}\tnote{2} & \CIRCLE{}
- & \LEFTcircle{}\tnote{3}\\
+ & \CIRCLE{}\tnote{3}\\
Simple type system & \CIRCLE{} & \CIRCLE{} & \Circle{}
& \CIRCLE{} & \CIRCLE{} & \Circle{}
& \LEFTcircle{}\tnote{4}\\
\end{threeparttable}
\end{table}
+\section{Conclusion}%
+Classy deep embedding is a novel organically grown embedding technique that alleviates deep embedding from the extensibility problem in most cases.
+
+By abstracting the semantics functions to type classes they become overloaded in the language constructs.
+Thus, making it possible to add new language constructs in a separate type.
+These extensions are brought together in a special extension constructor residing in the main data type.
+This extension case is overloaded by the language construct using a data type containing the class dictionary.
+As a result, orthogonal extension is possible for language constructs and semantics using only little syntactic overhead or type annotations.
+The basic technique only requires---well established through history and relatively standard---existential data types.
+However, if needed, the technique generalises to \glspl{GADT} as well, adding rank-2 types to the list of type system requirements as well.
+Finally, the abstract syntax tree remains observable which makes it suitable for intensional analyses, albeit using occasional dynamic typing for truly cross-extensional transformations.
+
+Defining reusable expressions overloaded in semantics or using multiple semantics on a single expression requires some boilerplate still, getting around this remains future work.
+\Cref{sec:classy_reprise} shows how the boilerplate can be minimised using advanced type system extensions.
+
\section*{Acknowledgements}
This research is partly funded by the Royal Netherlands Navy.
Furthermore, I would like to thank Pieter and Rinus for the fruitful discussions, Ralf for inspiring me to write a functional pearl, and the anonymous reviewers for their valuable and honest comments.
In classy deep embedding, the \gls{DSL} datatype is parametrised by a type variable providing a witness to the interpretation on the language.
When using multiple interpretations, these need to be bundled in a data type.
Using the \gls{GHC}'s \GHCmod{ConstraintKind} extension, we can make these witnesses explicit, tying into \gls{HASKELL}'s type system immediately.
-Furthermore, this constraint does not necessarily has to be a single constraint, after enabling \GHCmod{DataKinds} and \GHCmod{TypeOperators}, we can encode lists of witnesses instead.
+Furthermore, this constraint does not necessarily has to be a single constraint, after enabling \GHCmod{DataKinds} and \GHCmod{TypeOperators}, we can encode lists of witnesses instead \citep{yorgey_giving_2012}.
The data type for this list of witnesses is \haskelllhstexinline{Record} as shown in \cref{lst_cbde:record_type}.
This \gls{GADT} is parametrised by two type variables.
The first type variable (\haskelllhstexinline{dt}) is the type or type constructor on which the constraints can be applied and the second type variable (\haskelllhstexinline{clist}) is the list of constraints constructors itself.
\end{lstHaskellLhstex}
Furthermore, we define a type class (\haskelllhstexinline{In}) that allows us to extract explicit dictionaries \haskelllhstexinline{Dict} from these records if the constraint can is present in the list.
-Since the constraints become available as soon as the \haskelllhstexinline{Cons} constructor is matched, the implementation is a trivial type-level list traversal.
+Since the constraints become available as soon as the \haskelllhstexinline{Cons} constructor is matched, the implementation is a type-level list traversal.
\begin{lstHaskellLhstex}[caption={Membership functions for constraints}]
class c `In` cs where
e1 = neg (neg (Lit 42 `Add` (Lit 38 `subt` Lit 4)))
\end{lstHaskellLhstex}
-Finally, using the \GHCmod{TypeFamilies} extension, type families can be created for bundling \haskelllhstexinline{`In`} constraints (\haskelllhstexinline{UsingExt}) and \haskelllhstexinline{CreateRecord} constraints (\haskelllhstexinline{DependsOn}), making the syntax even more descriptive.
-E.g.\ \haskelllhstexinline{UsingExt '[A, B, C] c} expands to \haskelllhstexinline{(CreateRecord (A c) c, CreateRecord (B c) c, CreateRecord (C c) c)} and \haskelllhstexinline{DependsOn '[A, B, C] s} expands to \haskelllhstexinline{(A `In` s, B `In` s, C `In` s)}.
+Finally, using the \GHCmod{TypeFamilies} extension, type families can be created for bundling \haskelllhstexinline{`In`} constraints (\haskelllhstexinline{UsingExt}) and \haskelllhstexinline{CreateRecord} constraints \mbox{(\haskelllhstexinline{DependsOn})}, making the syntax even more descriptive.
+E.g.\ \mbox{\haskelllhstexinline{UsingExt '[A, B, C] c}} expands to\newline\haskelllhstexinline{(CreateRecord (A c) c, CreateRecord (B c) c, CreateRecord (C c) c)}.
+Similarly, \haskelllhstexinline{DependsOn '[A, B, C] s} expands to \haskelllhstexinline{(A `In` s, B `In` s, C `In` s)}.
\begin{lstHaskellLhstex}
type family UsingExt cs c :: Constraint where
\section{Data types and definitions}%
\label{sec:cde:appendix}
+This appendix collects all definitions omitted for brevity.
+
\lstset{basicstyle=\tt\footnotesize}
\begin{lstHaskellLhstex}[caption={Data type definitions.}]
data Sub_g d a where
\newcommand{\orcid}[1]{\href{https://orcid.org/#1}{\hspace{1mm}\includegraphics[width=1em]{orcid}\hspace{2mm} https://orcid.org/#1}}
\usepackage{tikz}
+% Index
+%\usepackage{makeidx}
+%\makeindex% Enable the index
+
+% Custom enumerations
+\usepackage[inline,shortlabels]{enumitem}
+\setlist{noitemsep}
+\setlist[description]{leftmargin=\parindent}
% Hyperlinks and metadata
\usepackage[hyphens]{url}
\def\MakeUppercase#1{}%
}
-% Index
-%\usepackage{makeidx}
-%\makeindex% Enable the index
-
-% Custom enumerations
-\usepackage[inline,shortlabels]{enumitem}
-\setlist{noitemsep}
-\setlist[description]{leftmargin=\parindent}
-
% Initialize the glossaries
\makeglossaries%
\input{glossaries}
\ifSubfilesClassLoaded{%
\setcounter{tocdepth}{3}
- \frontmatter
+ \frontmatter%
\frontmatterfancy%
\tableofcontents%
\input{subfileprefixsmall}%
-}{%
-}
+}{}%
\ifSubfilesClassLoaded{%
\mainmatter%
}{%
-}
+}%
Deep embedding.
\section{Future work}
-The \gls{MTASK} systems is a proof-of-concept system for integrating \gls{IOT} edge devices.
+The \gls{MTASK} systems is a proof-of-concept system for integrating \gls{IOT} edge devices
Edge computing
\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}
+It is a 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}).
+\Cref{sec_t4t:TiredvsTierless} contains an elaborate related work section regarding tierless systems in general.
\subsection{Interpretation}\label{sec:related_int}
-There are a myriad of interpreted programming languages available for some of the bigger devices.
+There are a myriad of interpreted programming languages available for some of the bigger more powerful edge 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.
+All of these languages, except the Lisp dialect uLisp (see \cref{sec:related_fp}), are imperative and do not support multiasking 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}.
+Another 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.
+\Citet{baccelli_reprogramming_2018} provide a single language \gls{IOT} system based on the RIOT \gls{OS} that allows runtime deployment of code snippets called containers.
+Both client and server are written in JavaScript.
+However, there is no integration between the client and the server other than that they are programmed from a single source.
+Mat\`e is an example of an early tierless sensor network framework where devices are provided with a virtual machine using TinyOS for dynamic provisioning \citep{levis_mate_2002}.
\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{}.
+\todo{uit\-brei\-den?}
\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.
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.
+\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}
+\subsection{Multitasking}\label{sec:related_multi}
Applications for tiny computers are often parallel in nature.
Tasks like reading sensors, watching input devices, operating actuators and maintaining communication are often loosely dependent on each other and are preferably executed in parallel.
Microcontrollers often do not benefit from an \gls{OS} due to memory and processing constraints.
This results in hard to maintain, error prone and unscalable spaghetti code.
There are many solutions to overcome this problem in imperative languages.
-
If the host language is a functional language (e.g.\ the aforementioned scheme variants) multitasking can be achieved without this burden relatively easy using continuation style multiprocessing \citep{wand_continuation-based_1980}.
Writing in this style is complicated and converting an existing program in this continuation passing style results in relatively large programs.
Furthermore, there is no built-in thread-safe communication possible between the tasks.
\end{threeparttable}
\end{table}
+\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 are both event driven---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 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 \citep{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.
+
\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}
+\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.
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}}
+\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.
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}}
+\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}.
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}}
+\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}.
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}
+\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 quantitatively 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}.
For example, the atmega328p in the \gls{ARDUINO} UNO is rated for 10000 write cycles.
While this sounds like a lot, if new tasks are sent to the device every minute or so, a lifetime of not even seven days is guaranteed.
Hence, for dynamic applications, generating code at run-time for interpretation on the device is necessary.
-This byte code is then interpreted on MCUs with very little memory and processing power and thus save precious write cycles of the program memory.
+This byte code is then interpreted on microcontrollers with very little memory and processing power and thus save precious write cycles of the program memory.
precious write cycles of the program memory.
In order to provide the device with the tools to interpret the byte code, it is programmed with a \gls{RTS}, a customisable domain-specific \gls{OS} that takes care of the execution of tasks but also low-level mechanisms such as the communication, multi tasking, and memory management.
\todo{plaa\-tje van me\-mo\-ry hier}
\todo{pseu\-do\-code hier van de ex\-e\-cu\-tie}
+\subsection{C code generation}
+
%TODO evt subsubsections verwijderen
\subsection{Communication}
In the first phase, the communication channels are processed.
Terms in our little toy language can be overloaded in their interpretation, they are just an interface.
For example, $1+5$ is written as \cleaninline{add (lit 1) (lit 5)} and has the type \cleaninline{v Int \| literals, addition v}.
-\todo{hier nog uit\-leg\-gen hoe je meer\-de\-re in\-ter\-pre\-ta\-tions kunt ge\-brui\-ken?}
+However, due to the way polymorphism is implemented in most functional languages, it is not always straightforward to use multiple interpretations in one function.
+Creating such a function, e.g.\ one that both prints and evaluates an expression, requires rank-2 polymorphism (see \cref{lst:rank2_mtask}).
\section{Interpretations}
This section describes all \gls{MTASK}'s interpretations.
repositories / phd-thesis.git / commitdiff