Finally, it provides a detailed overview of the contributions.
\end{chapterabstract}
-\todo[inline]{\etc{} toch als etc.\ ty\-pe\-se\-ten?}
+\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.
By utilising advanced compiler technologies, much of the internals, communications, and interoperations between the tiers\slash{}layers of the applications is automatically generated.
From a single declarative specification of the work required, the compiler makes a ready-for-work application consisting of interconnected components for all tiers.
For example, the \gls{TOP} system \gls{ITASK} can be used to program all layers of a multi-user distributed web applications from a single source specification.
-Unfortunately, because the abstraction level is so demanding, the hardware requirements are excessive for \gls{TOP} systems such as \gls{ITASK}.\todo[inline]{dit beter uitleggen. \gls{ITASK} is ook een \gls{DSL}, waarom werkt dit niet? \gls{ITASK} is geimplementeerd is een GP taal, en dat maakt het aantal abstractielagen groter?}
+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.
\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}.
-\todo[inline]{Hier een overzichtje van de chapters dan? Dat maakt hence ook duidelijker.}
+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[inline]{%
- Kunnen die poten van network er niet af? Ik vind ze eigenlijk juist mooi.
-
- Kan dit niet dezelfde elementen en namen hebben als het TIOT artikel? Synchroniseren met TIOT is lastig, nu heb ik het gelijk aan TOSD proberen te maken.
-}
+\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 programming language to be interpreted, so-called \glspl{DSL}.\todo[inline]{Dat is geen algemene eigenschap van DSLs of TOP DSLs, anders konden we wel iTask op een edge device draaien: over hebben}
+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?}
\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[inline]{Hier heb je toch juist geen extra leercurve, je ziet niets van de implementatietaal}
+\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}.
\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.\todo[inline]{Als dese LSOC anders is dan IOT dan moet je dat uitleggen: oké}
+Instead of dividing problems into \gls{LSOC} \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
\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[inline]{Strange item in this list. I expect something like object types in the application}
+ \todo{Stran\-ge item: from tosd paper}
The \gls{UOD} is explicitly and separately modelled by the relations that exist in the functions of the host language.
\end{description}
+This figure differs from the presented \gls{IOT} architecture because one describes the software architecture and the other a software development model.
+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.
+\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[inline]{Dit misschien hier uitbreiden en de engine en de language definieren?}
-\todo[inline]{Laat dit meer op figuur 1 lijken, maar dan zonder het edge level: Ik had hier een paragraaf uitleg over hoe TSOD mapt op IOT, maar dat moest eruit volgens Rinus}
-%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.
-%\t odo{Is deze \P\ dui\-de\-lijk genoeg of \"uberhaupt nodig?}
+\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}.
Browsers are powering \gls{ITASK}'s perception 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.
+The allowed task value transitions are shown in \cref{fig:taskvalue}.
+
+\begin{figure}
+ \centering
+ \includestandalone{taskvalue}
+ \caption{Transition diagram for task values in \gls{ITASK}.}%
+ \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[inline]{Voorbeeldje uitbreiden met parallel en shares}
+\todo{Voorbeeldje uitbreiden met parallel en shares}
\begin{figure}
\centering
\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}.
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 code and a screenshot of an interactive \imtask{} application for blinking \pgls{LED} on the microcontroller every dynamically changeable interval.
-\Crefrange{lst:intro:itask_fro}{lst:intro:itask_to} show the \gls{ITASK} part.
-First \pgls{SDS} is defined to communicate the blinking interval, then the \gls{MTASK} is connected using \cleaninline{withDevice}.
+\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.
+Using \cleaninline{enterInformation}, the connection specification of the \gls{TCP} device is queried (\cref{lst:intro_enterDevice}).
+\Cref{lst:intro_withshared} defines \pgls{SDS} to communicate the blinking interval.
+Then the \gls{MTASK} is connected using \cleaninline{withDevice} at \cref{lst:intro_withdevice}.
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.
-\begin{lstClean}[numbers=left,caption={\Imtask{} interactive blinking.},label={lst:intro_blink}]
-interactiveBlink :: Task Int[+\label{lst:intro:itask_fro}+]
-interactiveBlink =
- enterInformation [] <<@ Hint "Enter device information"
- >>? \spec->withShared 500 \iInterval->[+\label{lst:intro_withshared}+]
- withDevice spec \dev->
- liftmTask (intBlink iInterval) dev[+\label{lst:intro_liftmtask}+]
- -|| (Hint "Interval (ms)" @>> updateSharedInformation [] iInterval)[+\label{lst:intro_editor}+][+\label{lst:intro:itask_to}+]
-\end{lstClean}
+\cleaninputlisting[firstline=10,lastline=18,numbers=left,caption={\Imtask{} interactive blinking.},label={lst:intro_blink}]{lst/blink.icl}
\begin{figure}
\centering
\begin{subfigure}{.5\textwidth}
\centering
- \includegraphics[width=.95\linewidth]{blink1g}
+ \includegraphics[width=.975\linewidth]{blink1g}
\caption{Device selection.}
\end{subfigure}%
\begin{subfigure}{.5\textwidth}
\centering
- \includegraphics[width=.95\linewidth]{blink2g}
+ \includegraphics[width=.975\linewidth]{blink2g}
\caption{Changing the interval.}
\end{subfigure}
\caption{Screenshots for the interactive blink application.}%
The main expression of the program calls the \cleaninline{blink} function with an initial state.
This function on \crefrange{lst:intro:blink_fro}{lst:intro:blink_to} first reads the interval \gls{SDS}, waits the specified delay, writes the state to the \gls{GPIO} pin and calls itself recursively using the inverse of the state.
-\begin{lstClean}[numbers=left,caption={\Gls{MTASK} part of the interactive blinking application.},label={lst:intro_blink_mtask}]
-intBlink :: (Shared sds Int) -> Main (MTask v Int)
- | mtask, liftsds v & RWShared sds[+\label{lst:intro:mtask_fro}+]
-intBlink iInterval =
- declarePin D13 PMOutput \ledPin->[+\label{lst:intro:declarePin}+]
- liftsds \mInterval=iInterval[+\label{lst:intro:liftsds}+]
- In fun \blink=(\st->[+\label{lst:intro:blink_fro}+]
- getSds mInterval
- >>=. \i->delay i
- >>|. writeD ledPin st
- >>|. blink (Not st))[+\label{lst:intro:blink_to}+]
- In {main = blink true}[+\label{lst:intro:mtask_to}+]
-\end{lstClean}
+\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}
\subsection{Other \texorpdfstring{\glsxtrshort{TOP}}{TOP} languages}
While \gls{ITASK} conceived \gls{TOP}, it is not the only \gls{TOP} system.
repositories / phd-thesis.git / commitdiff