Finally, it provides a detailed overview of the contributions.
\end{chapterabstract}
-\todo[inline]{\etc{} toch als etc.\ ty\-pe\-se\-ten?}
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.
This is where \glspl{DSL} must be brought into play.
\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}.
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.
-}
\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}.
\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}
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}
\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
- \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[inline]{Strange item in this list. I expect something like object types in the application}
+ \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}
-\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?}
-
+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{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?}
+%
\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.
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}.
-
-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}
+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
- \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}
+ \includestandalone{taskvalue}
+ \caption{Transition diagram for task values in \gls{ITASK}.}%
+ \label{fig:taskvalue}
\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}+]
+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.
-derive class iTask Person, Gender[+\label{lst:dt_derive}+]
+\begin{figure}
+ \centering
+ \includegraphics[width=.75\linewidth]{todo0g}
+ \caption{The \gls{UI} for the shared to-do list \gls{ITASK}.}%
+ \label{fig:todo}
+\end{figure}
-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.
\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 / blobdiff