Finally, it provides a detailed overview of the contributions.
\end{chapterabstract}
-\todo{\etc{} toch als etc.\ ty\-pe\-se\-ten?: nee}
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}}.
Each of these senses, acts, or otherwise interacts with people, other computers, and the environment surrounding us.
Despite their immense diversity, they are all computers.
It is implemented in \gls{CLEAN} and executes also in \gls{CLEAN}'s run time.
The final executable is very low level and contains all these abstraction levels, this results in increased hardware requirements.
The high hardware requirements are no problem for regular computers but impractical for the average edge device.
-\todo{dit aan\-ge\-past en be\-spre\-ken}
This is where \glspl{DSL} must be brought into play.
\Glspl{DSL} are programming languages created with a specific domain in mind.
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}.
-\todo{Hier een o\-ver\-zicht v.d.\ chap\-ters ge\-ge\-ven}
Hence, the chapters are best read in order.
\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.
When describing \gls{IOT} systems, a tiered---or layered---architecture is often used for compartmentalisation.
The number of tiers heavily depends on the required complexity of the model.
For the intents and purposes of this thesis, the layered architecture as shown in \cref{fig:iot-layers} is used.
-\todo{ik vind de poten mooi\\namen met tiot syncen: overleggen}
\begin{figure}
\centering
With interpretation, a specialized interpreter is flashed in the program memory once it receives the program code to execute at run time.
Therefore, as the programs are not stored in the flash memory, it does not wear out.
It is challenging to create interpreters for small edge devices due to the severe hardware restrictions.
-However, the hardware requirements can be reduced by embedding domain-specific data into the langauge, so called \gls{DSL}; and the interpreter, a domain-specific \gls{OS}.\todo{ar\-gu\-ment zo ster\-ker?}
+However, the hardware requirements can be reduced by embedding domain-specific data into the langauge, so called \gls{DSL}; and the interpreter, a domain-specific \gls{OS}.
\section{\texorpdfstring{\Glsxtrlongpl{DSL}}{Domain-specific languages}}%
\label{sec:back_dsl}
\glspl{DSL} where historically created as standalone languages, meaning that all machinery is developed solely for the language.
The advantage of this approach is that the language designer is free to define the syntax and type system of the language as they wish, not being restricted by any constraint.
Unfortunately it also means that they need to develop a compiler or interpreter, and all the scaffolding for the language, making standalone \glspl{DSL} costly to create.
-\todo{Hier heb je toch juist geen extra leercurve, je ziet niets van de implementatietaal}
Examples of standalone \glspl{DSL} are regular expressions, make, yacc, XML, SQL, \etc.
The dichotomous approach is embedding the \gls{DSL} in a host language, i.e.\ \glspl{EDSL} \citep{hudak_modular_1998}.
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}.
Tasks written using \gls{MTASK} are dynamically compiled to byte code for an edge device and is therefore a heterogeneous \gls{DSL}.
-\todo[inline]{Welk deel van mTask is ``largely, or completely, ignorant of the existence of the other parts of the system.'' Lijkt me een rare definitie die niet echt van toepassing is: het RTS, het heeft geen idee van de taal of de server, dat is een black box, alleen van de gecompileerde code.}
\section{\texorpdfstring{\Glsxtrlong{TOP}}{Task-oriented programming}}%
\label{sec:back_top}
\begin{figure}
\centering
- \begin{subfigure}[t]{.5\textwidth}
- \centering
- \includestandalone{traditional}
- \caption{\Gls{LSOC} approach.}
- \end{subfigure}%
- \begin{subfigure}[t]{.5\textwidth}
- \centering
- \includestandalone{tosd}
- \caption{\Gls{TOSD} approach.}
- \end{subfigure}
- \caption{Separation of concerns in a traditional setting compared to \gls{TOSD} (adapted from \citep[\citepage{20}]{wang_maintaining_2018}).}%
+ \includestandalone{tosd}
+ \caption{Separation of concerns in \gls{TOSD} (adapted from \citep[\citepage{20}]{wang_maintaining_2018}).}%
\label{fig:tosd}
\end{figure}
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[Programming language (\glsxtrshort{UOD}):]
- \todo{Stran\-ge item: from tosd paper}
+ \item[\Glsxtrshort{UOD} (programming language):]
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 one describes the software architecture and the other a software development model.
+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.
+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.
-Applying the concepts of \gls{LSOC} to \gls{IOT} systems can be done in two ways.
-Firstly, edge devices can be seen as simple resources, thus accessed through the resource access layer.
-The second view is that edge devices contain miniature \gls{LSOC} systems in itself as well.
-In \gls{TOSD} the same can be applied.
-The individual components in the miniature systems, the tasks, the \glspl{SDS}, are connected to the main system.
+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?}
-\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?}
-
+%\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}.
From the structural properties of the data types, the entire user interface is automatically generated.
\label{fig:taskvalue}
\end{figure}
-As an example, \cref{lst:enter_person,fig:enter_person} show the \gls{ITASK} code and the corresponding \gls{UI} for a simple task for entering information about a person and viewing the entered result after completion.
-From the data type definitions (\cref{lst:dt_fro,lst:dt_to}), using generic programming (\cref{lst:dt_derive}), the \glspl{UI} for the data types are automatically generated.
-Using task combinators (e.g.\ \cleaninline{>>!} at \cref{lst:task_comb}), the tasks can be combined in sequence.
-Only when the user enters a complete value in the web editor, then the continue button enables and the result can be viewed.
-Special combinators (e.g.\ \cleaninline{@>>} at \cref{lst:task_ui}) are used to tweak the \gls{UI} to display informative labels.
-\todo{Voorbeeldje uitbreiden met parallel en shares}
+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.
+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}).
+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
- \begin{subfigure}{.5\textwidth}
- \centering
- \includegraphics[width=.95\linewidth]{person0g}
- \caption{Initial editor.}
- \end{subfigure}%
- \begin{subfigure}{.45\textwidth}
- \centering
- \includegraphics[width=.95\linewidth]{person1g}
- \caption{Completed editor.}
- \end{subfigure}
- \begin{subfigure}{.5\textwidth}
- \centering
- \includegraphics[width=.95\linewidth]{person2g}
- \caption{View the result.}
- \end{subfigure}
- \caption{The \gls{UI} for entering a person in \gls{ITASK}.}%
- \label{fig:enter_person}
+ \includegraphics[width=.75\linewidth]{todo0g}
+ \caption{The \gls{UI} for the shared to-do list \gls{ITASK}.}%
+ \label{fig:todo}
\end{figure}
-\begin{lstClean}[numbers=left,caption={The code for entering a person in \gls{ITASK}.},label={lst:enter_person}]
-:: Person = { name :: String, gender :: Gender, dateOfBirth :: Date }[+\label{lst:dt_fro}+]
-:: Gender = Male | Female | Other String[+\label{lst:dt_to}+]
-
-derive class iTask Person, Gender[+\label{lst:dt_derive}+]
-
-enterPerson :: Task Person
-enterPerson
- = Hint "Enter a person:" @>> enterInformation [][+\label{lst:task_ui}+]
- >>! \result->Hint "You Entered:" @>> viewInformation [] result[+\label{lst:task_comb}+]
-\end{lstClean}
+\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}
\subsection{\texorpdfstring{\Gls{MTASK}}{MTask}}
\Gls{ITASK} seems an obvious candidate at first glance for extending \gls{TOP} to \gls{IOT} edge devices.
\input{subfilepreamble}
+\setcounter{chapter}{2}
+
\begin{document}
\input{subfileprefix}
\chapter{\texorpdfstring{\Glsxtrlong{TOP} for the \glsxtrlong{IOT}}{Task-oriented programming for the internet of things}}%
\end{itemize}
\end{chapterabstract}
-The edge layer of \gls{IOT} systems predominantly contains of microcontrollers.
+The edge layer of \gls{IOT} systems predominantly consists of microcontrollers.
Microcontrollers are tiny computers designed specifically for embedded applications.
-They therefore only have a soup\c{c}on of memory, have a slow processor, come with many energy efficient sleep modes and have a lot of peripheral support such as \gls{GPIO} pins.
+They therefore only have a soup\c{c}on of memory and have a slow processor.
+However, they also come with energy efficient sleep modes and have a lot of peripheral support such as \gls{GPIO} pins.
Usually, programming microcontrollers requires an elaborate multi-step toolchain of compilation, linkage, binary image creation, and burning this image onto the flash memory of the microcontroller in order to compile and run a program.
The programs are usually cyclic executives instead of tasks running in an operating system, i.e.\ there is only a single task that continuously runs on the bare metal.
\Cref{tbl:mcu_laptop} compares the hardware properties of a typical laptop with two very popular microcontrollers.
\end{table}
Different models of microcontrollers require their own vendor-provided drivers, hardware abstraction layer, compilers and \glspl{RTS}.
-There are many platforms that abstract away from this such as \gls{MBED} and \gls{ARDUINO} of which \gls{ARDUINO} is specifically designed for education and prototyping and hence used here.
+There are many platforms that abstract away from this such as \gls{MBED} and \gls{ARDUINO}.
+\Gls{ARDUINO} is specifically designed for education and prototyping and hence used here to show traditional microcontroller programming.
+
The popular \gls{ARDUINO} \ccpp{} dialect and accompanying libraries provide an abstraction layer for common microcontroller behaviour allowing the programmer to program multiple types of microcontrollers using a single language.
Originally it was designed for the in-house developed open-source hardware with the same name but the setup allows porting to many architectures.
It provides an \gls{IDE} and toolchain automation to perform all steps of the toolchain with a single command.
-\subsection{\texorpdfstring{\Glsxtrshort{TOP} for the \glsxtrshort{IOT}}{TOP for the IoT}}
+\section{\texorpdfstring{\Glsxtrshort{TOP} for the \glsxtrshort{IOT}}{TOP for the IoT}}
\Gls{TOP} is a programming paradigm that allows multi-tier systems to be generated from a single declarative source.
\Gls{ITASK} is a general-purpose \gls{TOP} system for programming distributed web applications.
These distributed web applications often form the core of \gls{IOT} applications as well but integrating these devices in \gls{ITASK} is not straightforward.
\Gls{ITASK} targets relatively fast but energy-hungry systems with large amounts of \gls{RAM} and a speedy connections.
-Edge devices in \gls{IOT} systems are typically slow but energy efficient and do not have the memory to run the naturally heap-heavy functional programs that \gls{ITASK} results in.
-\Gls{MTASK} bridges this gap by providing a \gls{TOP} \gls{DSL} for \gls{IOT} edge devices that can, because domain-specific knowledge is built in, run on hardware with much less memory and processor speed.
+Edge devices in \gls{IOT} systems are typically slow but energy efficient and do not have the memory to run the naturally heap-heavy functional programs that \gls{ITASK} programs are.
+\Gls{MTASK} bridges this gap by providing a \gls{TOP} \gls{DSL} for \gls{IOT} edge devices that can, because domain-specific knowledge is embedded in the language and execution platform, run on hardware with much less memory and processor speed.
The following sections compare traditional microcontroller programming with programming the devices using \gls{MTASK}.
\section{Hello world!}
repositories / phd-thesis.git / commitdiff
