\glsresetall%
%\begin{center}
%\noindent%
-The number of computers around us is growing exponentially, thus increasing the complexity of the systems in which they operate.
+The number of computers around us is growing exponentially, compounding the complexity of the systems in which they operate.
Many of these computers are \emph{edge devices} operating in \gls{IOT} systems.
-Within these orchestras of computers, they interact with their environment using sensors and actuators.
-Edge devices often use cheap microcontrollers designed for embedded applications.
-They, therefore, have little memory, unhurried processors, and slow communication but are tiny and energy efficient.
-Programming \gls{IOT} systems is complex due to their dynamic, interactive, distributed, collaborative, multi-tiered, and multitasking nature.
-This is impeded even more by semantic friction that arises through different hardware and software characteristics between the tiers.
+Within these orchestrations of computers, they interact with the environment using sensors and actuators.
+Edge devices often use low-cost microcontrollers designed for embedded applications.
+They have little memory, unhurried processors, and are slow in communication.
+Yet they are small and energy efficient.
+Programming \gls{IOT} systems is complex since they are dynamic, interactive, distributed, collaborative, multi-tiered, and multitasking in nature.
+This is impeded more so by semantic friction that arises through different hardware and software characteristics between tiers.
A solution is found in \gls{TOP}.
%A solution is found in the declarative programming paradigm \gls{TOP}.%, a declarative programming paradigm.
During execution, the current value of the task is observable, and other tasks can act upon it.
Collaboration patterns can be modelled by combinding and transforming tasks into compound tasks.
From this declarative description of the work, a ready-for-work computer system is generated that guides the user in doing the work.
-An example of a \gls{TOP} system is \gls{ITASK}, a language for describing interactive web applications.
+An example of a \gls{TOP} system is \gls{ITASK}, a language which describes interactive web applications.
Programming edge devices would benefit from \gls{TOP} as well.
However, it is not straightforward to run \gls{TOP} systems on resource-constrained edge devices.
-This dissertation shows how to orchestrate complete \gls{IOT} systems using \gls{TOP}.
+This dissertation demonstrates how to orchestrate complete \gls{IOT} systems using \gls{TOP}.
%
First, I present advanced \gls{DSL} embedding techniques.
Then \gls{MTASK} is shown, a \gls{TOP} \gls{DSL} for \gls{IOT} edge devices, embedded in \gls{ITASK}.
Tasks are constructed and compiled at run time.
-This allows tasks to be tailor-made for the work that needs to be done.
+This allows tasks to be tailor-made for the current work requirements.
The compiled task is sent to the device for interpretation.
-For a device to be used in an \gls{MTASK} system, it needs to be programmed once with a lightweight domain-specific \gls{OS}.
-This \gls{OS} executes tasks in an energy-efficient way and automates all communication and data sharing.
+For a device to be used in an \gls{MTASK} system, it must to be programmed once with a lightweight domain-specific \gls{OS}.
+This \gls{OS} executes tasks in an energy-efficient way and automates all communications and data sharing.
All aspects of the \gls{MTASK} system are shown: example applications, language design, implementation details, integration with \gls{ITASK}, and green computing facilities.
When using \gls{MTASK} in conjunction with \gls{ITASK}, entire \gls{IOT} systems are programmed tierlessly from a single source, language, paradigm, high abstraction level, and type system.
The dissertation concludes with a comparison between tierless programming, in particular in \gls{MTASK}, and traditional tiered programming.
-It shows that many problems such as semantic friction, maintainability, robustness, and interoperation safety are mitigated when using tierless programming.
+It demonstrates that many problems such as semantic friction, maintainability, robustness, and interoperation safety are mitigated when using tierless programming.
%This is a summary of 350--400 words.
%\end{center}
\end{document}
This chapter concludes the dissertation and reflects on the work.
\end{chapterabstract}
\section{Reflections}
-While the term \gls{IOT} has already been known for almost thirty years, the exponential growth of the number of \gls{IOT} edge devices is really ramping up recently.
-\todo{chap\-ter\-ab\-stract weg?}
-Programming layered systems such as \gls{IOT} systems is very complex because on each layer of the system, different computers, hardware architectures, programming languages, programming paradigms, and abstraction levels are required.
+\todo[inline]{chap\-ter\-ab\-stract weg?}
+The term \gls{IOT} has already been known for almost thirty years.
+Only recently, the exponential growth of the number of \gls{IOT} edge devices is really ramping up.
+Programming layered systems such as \gls{IOT} systems is very complex.
+The complexity mainly arises from the fact that each layer of the system is built up using different computers, hardware architectures, programming languages, programming paradigms, and abstraction levels.
This generates 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.
+Furthermore, \gls{IOT} systems become convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative.
\Gls{TOP} proves 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 shed light on orchestrating complete \gls{IOT} system using \gls{TOP}, specifically filling in the knowledge gap for edge devices in three episodes.
+This thesis sheds light on how to orchestrate complete \gls{IOT} systems using \gls{TOP}.
+It specifically fills in the knowledge gap for edge devices.
+The contributions are split up into three episodes.
-\Cref{prt:dsl} presented two novel techniques for embedding \glspl{DSL} in \gls{FP} languages: the classy deep \gls{EDSL} embedding technique and a way of generating boilerplate for data types using template metaprogramming.
+In \cref{prt:dsl}, two novel techniques for embedding \glspl{DSL} in \gls{FP} languages are presented: the classy deep \gls{EDSL} embedding technique and a way of generating boilerplate for data types using template metaprogramming.
In \gls{DSL} embedding techniques, one always has to make concessions.
Either it is easy to extend the language in language constructs or in interpretations but never both.
Tagless-final embedding offers a way of extending a shallowly embedded \gls{DSL} both in constructs and interpretations.
Classy deep embedding is the organically grown counterpart for deep embedding a \gls{DSL}.
It allows orthogonal extension of language constructs and interpretations with minimal boilerplate and no advanced type system extensions.
-Furthermore, when embedding a \gls{DSL} in a language, much of the machinery can be inherited.
+Furthermore, when embedding a \gls{DSL} in a language, much of the machinery is inherited.
However, data types are not automatically useable in the \gls{DSL} because the interfaces such as constructors, deconstructors and constructortests are not inherited.
I show how to automatically generate boilerplate for \glspl{DSL} in order to make data types first-class citizens in the \gls{DSL}.
The scaffolding is generated using template metaprogramming and quasiquotation is used to alleviate the programmer from the syntax burden.
-\Cref{prt:top} gave an overview of the \gls{MTASK} system, it's design, integration with \gls{ITASK}, implementation, and green computing facilities.
-Using advanced \gls{DSL} embedding technique, a \gls{TOP} \gls{DSL} for the \gls{IOT} edge devices can be created that allows programming the small microcomputers according to the same high abstraction level as on the server.
-The \gls{MTASK} system is a \gls{TOP} system for edge devices.
-It is fully integrated with \gls{ITASK} and hence allows the programmer to specify all layers of an \gls{IOT} system in a single specification.
-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:top} contains a complete overview of the \gls{MTASK} system: its design, integration with \gls{ITASK}, implementation, and green computing facilities.
+The \gls{MTASK} language is a unique domain-specific \gls{TOP} \gls{EDSL} designed system for edge devices.
+The system is fully integrated with the \gls{ITASK} system, a \gls{TOP} system for programming distributed web applications.
+In the \gls{ITASK} system, there are abstractions for details such as user interfaces, data storage, client-side platforms, and persistent workflows.
+The \gls{MTASK} language abstracts away from edge device specific details such as sensor and actuator access, heterogeneity in hardware, and multitasking and scheduling.
+Tasks in the \gls{MTASK} system are compiled at run time and sent to the device dynamically in order to support create dynamic systems where tasks are tailor-made for the current work requirements.
+This tight integration makes programming full \gls{IOT} systems using \gls{TOP} possible without major compromises.
+All layers of the entire \gls{IOT} system are specified in a single source, the same strong type system, and similar high abstraction level.
+Therefore, they are simultaneously checked by a single compiler, reducing interoperability problems.
+Furthermore, all communication and integration is automatically generated, reducing the interoperability even more.
+Using only three simple functions, devices are connected to \gls{ITASK} servers, \gls{MTASK} tasks are integrated in \gls{ITASK}, and \gls{ITASK} \glspl{SDS} accessed from within \gls{MTASK} tasks.
+\todo[inline]{benoem geïntroduceerde semantische wrijving? Het feit dat mTask strikter is?}
-\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 required to making these systems.
+In \Cref{prt:tvt}, traditional \gls{IOT} system programming, tiered programming, is qualitatively and quantitatively compared to tierless programming.
+The comparison demonstrates 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.
They contain many high-level tierless abstractions that the programmer has to master.
The low-level specific semantics of the final application may become more difficult to destill from the specification.
Finally, the system is quite monolithic.
-Changing a components within the system is easy if it already exists in the host language.
+Changing components within the system is easy if it already exists in the host language.
Adding new components to the system requires the programmer to add it to all complex components of the languages such as the compiler, and \gls{RTS}.
\input{subfilepostamble}
\end{chapterabstract}
There are at least 13.4 billion devices connected to the internet at the time of writing \citep{transformation_insights_current_2023}.
-Each of these sense, act, or otherwise interact with people, other computers, and the environment surrounding us.
-Despite their immense diversity, they are all computers.
+Each of these sense, act, or otherwise, interact with people, other computers, and the environment surrounding us.
+Despite their immense diversity in characteristics, they are all computers.
And as computers, they require software to operate.
An increasing amount of these connected devices are so-called \emph{edge devices} that operate in the \gls{IOT}.
-Edge devices are the leafs of the \gls{IOT} systems, they perform the interaction with the physical world and are often physically embedded in the fabric.
-They usually reside in hard-to-reach places such as light bulbs, smart electricity meters, or even farm animals.
+Edge devices are the leaves of the \gls{IOT} systems.
+They perform the interaction with the physical world and are often physically embedded in the fabric, residing usually in hard-to-reach places such as light bulbs, smart electricity meters, or even farm animals.
Microcontrollers are equipped with a lot of connectivity for integrating peripherals such as sensors and actuators.
The connectivity makes them very suitable to interact with their surroundings.
Typically, these edge devices are powered by microcontrollers.
Hence, microcontrollers are cheap; tiny; have little memory; and contain a slow, but energy-efficient processor.
Unlike the conductor in an orchestra waving their baton to instruct the ensemble of instruments, in the universe of software there is room for little error.
-Moreover, in dynamic \gls{IOT} applications, often there is not even a coordinating conductor.
-Even though edge devices—the instruments—come and go, perform their own pieces, or are instructed to perform a certain piece, they operate without a central authority.
+Moreover, in dynamic \gls{IOT} applications, there is not always a coordinating conductor.
+Even though edge devices---the instruments---come and go, perform their own pieces, or are instructed to perform a certain piece, they operate without a central authority.
In the traditional setting, an \gls{IOT} engineer has to program each device and their interoperation using different programming paradigms, programming languages, and abstraction levels.
-Thus resulting in semantic friction, which makes programming and maintaining \gls{IOT} systems a complex and error-prone process.
+This results in semantic friction, which makes programming and maintaining \gls{IOT} systems a complex and error-prone process.
This dissertation describes the research carried out around orchestrating these complex \gls{IOT} systems using \gls{TOP}.
\Gls{TOP} is an innovative tierless programming paradigm for interactive multi-layered systems.
\section{Reading guide}%
\label{lst:reading_guide}
This work is structured as a purely functional rhapsody.
-On Wikipedia, a musical rhapsody is defined as follows \citep{wikipedia_contributors_rhapsody_2022}:
+The \citet{wikipedia_contributors_rhapsody_2022} define a musical rhapsody is defined as follows:
\begin{quote}\emph{%
A \emph{rhapsody} in music is a one-movement work that is episodic yet integrated, free-flowing in structure, featuring a range of highly contrasted moods, colour, and tonality.}
\end{quote}
\end{quote}
Much later, CISCO states that the \gls{IOT} started when there were as many connected devices as there were people on the globe, i.e.\ around 2008 \citep{evans_internet_2011}.
-Today, \gls{IOT} is the term for a system of devices that sense the environment, act upon it and communicate with each other and the world they live in.
+Today, \gls{IOT} is the term for a system of devices that sense the environment, act upon it, and communicate with each other and the world they live in.
These connected devices are already in households all around us in the form of smart electricity meters, fridges, phones, watches, home automation, \etc.
When describing \gls{IOT} systems, a tiered---or layered---architecture is often used for compartmentalisation.
\subsection{Standalone and embedded}%
\label{sec:standalone_embedded}
-\glspl{DSL} where historically created as standalone languages, meaning that all machinery is developed solely for the language.
+\glspl{DSL} were 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.
Examples of standalone \glspl{DSL} are \TeX, make, yacc, XML, SQL, \etc.
is a short paper on the multitasking capabilities of \gls{MTASK} comparing it to traditional multitasking methods for \gls{ARDUINO}.
% \paragraph{Contribution}
% The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer.
- \item \emph{Simulation of a Task-\kern-1.25ptBased Embedded Domain Specific Language for the Internet of Things} \citep{koopman_simulation_2018}\footnotemark[\value{footnote}]
+ \item \emph{Simulation of a Task-\kern-1.25ptBased Embedded Domain Specific Language for the Internet of Things} \citep{koopman_simulation_2023}\footnotemark[\value{footnote}]
are the revised lecture notes for a course on the \gls{MTASK} simulator was provided at the 2018 \gls{CEFP}\slash{}\gls{3COWS} winter school in Ko\v{s}ice, Slovakia, January 22--26, 2018.
% \paragraph{Contribution}
% Pieter Koopman wrote and taught it, I helped with the software and research.
- \item \emph{Writing Internet of Things Applications with Task Oriented Programming} \citep{lubbers_writing_2019}\footnotemark[\value{footnote}]
+ \item \emph{Writing Internet of Things Applications with Task Oriented Programming} \citep{lubbers_writing_2023}\footnotemark[\value{footnote}]
are the revised lecture notes from a course on programming \gls{IOT} systems using \gls{MTASK} provided at the 2019 \gls{CEFP}\slash{}\gls{3COWS} summer school in Budapest, Hungary, June 17--21, 2019.
% \paragraph{Contribution}
% Pieter Koopman prepared and taught half of the lecture and supervised the practical session.
@techreport{transformation_insights_current_2023,
title = {Current {IoT} {Forecast} {Highlights}},
url = {https://transformainsights.com/research/forecast/highlights},
- institution = {Transforma Insights},
- author = {Transforma Insights},
+ institution = {{Transforma Insights}},
+ author = {{Transforma Insights}},
month = jan,
year = {2023},
note = {accessed-on: 2023-01-19},
file = {Lubbers et al. - 2019 - Interpreting Task Oriented Programs on Tiny Comput.pdf:/home/mrl/.local/share/zotero/storage/ATYSJXJ3/Lubbers et al. - 2019 - Interpreting Task Oriented Programs on Tiny Comput.pdf:application/pdf},
}
-@incollection{lubbers_writing_2019,
+@incollection{lubbers_writing_2023,
address = {Cham},
+ series = {Lecture {Notes} in {Computer} {Science}},
title = {Writing {Internet} of {Things} applications with {Task} {Oriented} {Programming}},
abstract = {The Internet of Things (IOT) is growing fast. In 2018, there was approximately one connected device per person on earth and the number has been growing ever since. The devices interact with the environment via different modalities at the same time using sensors and actuators making the programs parallel. Yet, writing this type of programs is difficult because the devices have little computation power and memory, the platforms are heterogeneous and the languages are low level. Task Oriented Programming (TOP) is a novel declarative programming language paradigm that is used to express coordination of work, collaboration of users and systems, the distribution of shared data and the human computer interaction. The mTask language is a specialized, yet full-fledged, multi-backend TOP language for IOT devices. With the bytecode interpretation backend and the integration with iTasks, tasks can be executed on the device dynamically. This means that —according to the current state of affairs— tasks can be tailor-made at run time, compiled to device-agnostic bytecode and shipped to the device for interpretation. Tasks sent to the device are fully integrated in iTasks to allow every form of interaction with the tasks such as observation of the task value and interaction with Shared Data Sources (SDSs). The application is —server and devices— are programmed in a single language, albeit using two embedded Domain Specific Languages (EDSLs).},
language = {en},
- booktitle = {Central {European} {Functional} {Programming} {School}: 8th {Summer} {School}, {CEFP} 2019, {Budapest}, {Hungary}, {July} 17–21, 2019, {Revised} {Selected} {Papers}},
- publisher = {Springer International Publishing},
+ number = {11950},
+ booktitle = {Composability, {Comprehensibility} and {Correctness} of {Working} {Software}, 8th {Summer} {School}, {Budapest}, {Hungary}, {June} 17–21, 2019, {Revised} {Selected} {Papers}},
+ publisher = {Springer},
author = {Lubbers, Mart and Koopman, Pieter and Plasmeijer, Rinus},
- year = {2019},
+ year = {2023},
note = {in-press. preprint at: https://arxiv.org/abs/2212.04193},
pages = {51},
file = {cefp.pdf:/home/mrl/.local/share/zotero/storage/VEWFI5DG/cefp.pdf:application/pdf},
file = {amlap2015.pdf:/home/mrl/.local/share/zotero/storage/H9WTW9TM/amlap2015.pdf:application/pdf;Will_Schuerman_AMLAP2015_Draft2.pdf:/home/mrl/.local/share/zotero/storage/BFBDDVIQ/Will_Schuerman_AMLAP2015_Draft2.pdf:application/pdf},
}
-@incollection{koopman_simulation_2018,
+@incollection{koopman_simulation_2023,
address = {Cham},
+ series = {Lecture {Notes} in {Computer} {Science}},
title = {Simulation of a {Task}-{Based} {Embedded} {Domain} {Specific} {Language} for the {Internet} of {Things}},
language = {en},
- booktitle = {Central {European} {Functional} {Programming} {School}: 7th {Summer} {School}, {CEFP} 2018, {Košice}, {Slovakia}, {January} 22–26, 2018, {Revised} {Selected} {Papers}},
- publisher = {Springer International Publishing},
+ number = {11916},
+ booktitle = {Composability, {Comprehensibility} and {Correctness} of {Working} {Software}, 7th {Winter} {School}, {Kosice}, {Slovakia}, {January} 22–26, 2018, {Revised} {Selected} {Papers}},
+ publisher = {Springer},
author = {Koopman, Pieter and Lubbers, Mart and Plasmeijer, Rinus},
- year = {2018},
+ year = {2023},
note = {in-press},
pages = {51},
}
\label{prt:top}
\subfile{top/4iot} % TOP for the IoT
\subfile{top/lang} % mTask DSL
-\subfile{top/int} % Integration with iTask
\subfile{top/imp} % Implementation
+\subfile{top/int} % Integration with iTask
\subfile{top/green} % Green computing
\subfile{top/finale} % Conclusion
keywords = {foreign function calls, multi-lingual type system, OCaml, multi-lingual type inference, flow-sensitive type system, FFI, foreign function interface, dataflow analysis, representational type}
}
-@INPROCEEDINGS{LubbersMIPRO,
- author={Lubbers, Mart and Koopman, Pieter and Plasmeijer, Rinus},
- booktitle={2019 42nd International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO)},
- title={Multitasking on Microcontrollers using Task Oriented Programming},
- year={2019},
- volume={},
- number={},
- pages={1587-1592},
- publisher={IEEE},
- address={Opatija, Croatia},
- doi={10.23919/MIPRO.2019.8756711}}
-
@inproceedings{plamauer2017evaluation,
title={Evaluation of micropython as application layer programming language on cubesats},
author={Plamauer, Sebastian and Langer, Martin},
The following chapters thoroughly introduce all aspects of the \gls{MTASK} system.
First the language setup and interface is shown in \cref{chp:mtask_dsl}.
-Then the interface for integrating \gls{MTASK} with \gls{ITASK} is provided in \cref{chp:integration_with_itask}.
-\Cref{chp:implementation} provides the implementation of the \gls{DSL}, the compilation schemes, instruction set and details on the interpreter.
+Then, \cref{chp:implementation} provides the implementation of the \gls{DSL}, the compilation schemes, instruction set and details on the interpreter.
+\Cref{chp:integration_with_itask} shows the integration of \gls{MTASK} and \gls{ITASK}.
\Cref{chp:green_computing_mtask} explains all the green computing aspects of \gls{MTASK}, i.e.\ task scheduling and processor interrupts.
Finally, \cref{chp:finale} concludes, and shows related work together with a short history of \gls{MTASK}.
\Gls{ITASK} abstracts away from the gritty details of interactive web applications such as program distribution, web applications, data storage, and user management.
The engine of \gls{MTASK} abstracts away of all technicalities such as communication, abstractions for sensors and actuators, interrupts and (multi) task scheduling.
-Devices are connected to the \gls{ITASK} system at run time using a single function that takes care of all the communication and error handling.
-When connected to a device, tasks written in the \gls{MTASK} \gls{DSL} can be lifted to \gls{ITASK} tasks.
+The \gls{MTASK} devices are connected to the \gls{ITASK} system at run time using a single function that takes care of all the communication and error handling.
+Any device equipped with the \gls{MTASK} \gls{RTS} can be used in the system and dynamically receive tasks for execution.
+This domain-specific \gls{OS} only needs to be programmed once, hence saving precious write cycles on the program memory.
+Once connected to a device, tasks written in the \gls{MTASK} \gls{DSL} can be lifted to \gls{ITASK} tasks.
The tasks are specified and compiled at run time, i.e.\ \gls{CLEAN} can be used as a macro language for constructing \gls{MTASK} tasks, tailor making them for the work that needs to be done.
When lifted, other tasks in the system can interact with the task through the usual means.
Furthermore, \gls{ITASK} \glspl{SDS} can be \emph{lowered} to \gls{MTASK} tasks as well, allowing for bidirectional automatic data sharing between \gls{MTASK} tasks and the \gls{ITASK} system.
-The \gls{MTASK} device is equipped with a domain-specific \gls{OS} that only needs to be programmed once after which the device can continuously receive new tasks.
\todo[inline]{Uitbreiden}
\section{Future work}
However, this version used a simplified version of \gls{MTASK} without functions.
This was later improved upon by creating a simplified interface where \glspl{SDS} from \gls{ITASK} could be used in \gls{MTASK} and the other way around \citep{lubbers_task_2018}.
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}.
+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_2023}.
\subsection{Transition to \texorpdfstring{\glsxtrlong{TOP}}{Task-oriented programming}}
The \gls{MTASK} language as it is now was introduced in 2018 \citep{koopman_task-based_2018}.
Later the byte code compiler and \gls{ITASK} integration was added to the language \citep{lubbers_interpreting_2019}.
Moreover, it was shown that it is very intuitive to write microcontroller applications in a \gls{TOP} language \citep{lubbers_multitasking_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}.
+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_2023}.
\subsection{\texorpdfstring{\Glsxtrlong{TOP}}{Task-oriented programming}}
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}.
\input{subfilepreamble}
-\setcounter{chapter}{5}
+\setcounter{chapter}{4}
\begin{document}
\input{subfileprefix}
\section{Compiler}
\subsection{Instruction set}
-The instruction set is a fairly standard stack machine instruction set extended with special \gls{TOP} instructions.
+The instruction set is a fairly standard stack machine instruction set extended with special \gls{TOP} instructions for creating task tree nodes.
+All instructions are housed in a \gls{CLEAN} \gls{ADT} and serialised to the byte representation using a generic function.
+Type synonyms (\cref{lst:type_synonyms}) are used to provide insight on the arguments of the instructions.
+Labels are always two bytes long, all other arguments are one byte long.
-\Cref{lst:instruction_type} shows the \gls{CLEAN} type representing the instruction set of which \cref{tbl:instr_task} gives detailed semantics.
-Type synonyms are used to provide insight on the arguments of the instructions.
-One notable instruction is the \cleaninline{MkTask} instruction, it allocates and initialises a task tree node and pushes a pointer to it on the stack.
-
-\begin{lstClean}[caption={The type housing the instruction set.},label={lst:instruction_type}]
+\begin{lstClean}[caption={Type synonyms for instructions arguments.},label={lst:type_synonyms}]
:: ArgWidth :== UInt8 :: ReturnWidth :== UInt8
:: Depth :== UInt8 :: Num :== UInt8
:: SdsId :== UInt8 :: JumpLabel =: JL UInt16
+\end{lstClean}
-//** Datatype housing all instructions
+\Cref{lst:instruction_type} shows an excerpt of the \gls{CLEAN} type that represents the instruction set.
+For example, shorthand instructions are omitted for brevity.
+Detailed semantics for the instructions are given in \cref{chp:bytecode_instruction_set}.
+One notable instruction is the \cleaninline{MkTask} instruction, it allocates and initialises a task tree node and pushes a pointer to it on the stack.
+
+\begin{lstClean}[caption={The type housing the instruction set.},label={lst:instruction_type}]
:: BCInstr
- //Return instructions
//Jumps
= BCJumpF JumpLabel | BCJump JumpLabel | BCLabel JumpLabel | BCJumpSR ArgWidth JumpLabel
| BCReturn ReturnWidth ArgWidth | BCTailcall ArgWidth ArgWidth JumpLabel
| BCArgs ArgWidth ArgWidth
//Task node creation and refinement
| BCMkTask BCTaskType | BCTuneRateMs | BCTuneRateSec
- //Task value ops
- | BCIsStable | BCIsUnstable | BCIsNoValue | BCIsValue
//Stack ops
| BCPush String255 | BCPop Num | BCRot Depth Num | BCDup | BCPushPtrs
//Casting
| BCAddI | BCSubI | ...
...
-//** Datatype housing all task types
:: BCTaskType
- = BCStableNode ArgWidth | ArgWidth
+ = BCStableNode ArgWidth | BCUnstableNode ArgWidth
// Pin io
| BCReadD | BCWriteD | BCReadA | BCWriteA | BCPinMode
// Interrupts
// Repeat
| BCRepeat
// Delay
- | BCDelay | BCDelayUntil //* Only for internal use
+ | BCDelay | BCDelayUntil
// Parallel
| BCTAnd | BCTOr
//Step
\Cref{lst:compiler_state} shows the data type for the state, storing:
function the compiler currently is in;
code of the main expression;
-context (see \todo{insert ref to compilation rules step here});
+context (see \cref{ssec:step});
code for the functions;
next fresh label;
a list of all the used \glspl{SDS}, either local \glspl{SDS} containing the initial value (\cleaninline{Left}) or lifted \glspl{SDS} (see \cref{sec:liftsds}) containing a reference to the associated \gls{ITASK} \gls{SDS};
Furthermore, redundant instructions (e.g.\ pop directly after push) are removed as well in order not to burden the code generation with these intricacies.
Finally the labels are resolved to represent actual program addresses instead of freshly generated identifiers.
After the byte code is ready, the lifted \glspl{SDS} are resolved to provide an initial value for them.
-The result---byte code, \gls{SDS} specification and perpipheral specifications---are the result of the process, ready to be sent to the device.
+The result---byte code, \gls{SDS} specification and perpipheral specifications---are the result of the process, ready to be sent to the device.
\section{Compilation rules}
This section describes the compilation rules, the translation from abstract syntax to byte code.
rtrn m = m >>| tell` [BCMkTask (bcstable m)]
\end{lstClean}
-\subsection{Step combinator}\label{ssec:step}
+\subsection{Sequential combinator}\label{ssec:step}
The \cleaninline{step} construct is a special type of task because the task value of the left-hand side may change over time.
Therefore, the continuation tasks on the right-hand side are \emph{observing} this task value and acting upon it.
In the compilation scheme, all continuations are first converted to a single function that has two arguments: the stability of the task and its value.
Compiling \cleaninline{getSds} is a matter of executing the \cleaninline{BCInterpret} representing the \gls{SDS}, which yields the identifier that can be embedded in the instruction.
Setting the \gls{SDS} is similar: the identifier is retrieved and the value is written to put in a task tree so that the resulting task can remember the value it has written.
-Lifted SDSs are compiled in a very similar way.\todo{deze \P{} moet naar integration?}
-The only difference is that there is no initial value but an iTasks SDS when executing the Clean function.
-A lens on this SDS converting \cleaninline{a} from the \cleaninline{Shared a} to a \cleaninline{String255}---a bytecode encoded version---is stored in the state.
-The encoding and decoding itself is unsafe when used directly but the type system of the language and the abstractions make it safe.
-Upon sending the mTask task to the device, the initial values of the lifted SDSs are fetched to complete the SDS specification.
+Lifted SDSs are compiled in a very similar way \cref{sec:liftsds}.
% VimTeX: SynIgnore on
\begin{lstClean}[caption={Backend implementation for the SDS classes.},label={lst:comp_sds}]
\end{lstClean}
% VimTeX: SynIgnore off
-\section{C code generation}\label{sec:ccodegen}
+\section{\texorpdfstring{\Gls{C}}{C} code generation}\label{sec:ccodegen}
All communication between the \gls{ITASK} server and the \gls{MTASK} server is type-parametrised.
From the structural representation of the type, a \gls{CLEAN} parser and printer is constructed using generic programming.
Furthermore, a \ccpp{} parser and printer is generated for use on the \gls{MTASK} device.
\input{subfilepreamble}
+\setcounter{chapter}{5}
+
\begin{document}
\input{subfileprefix}
\chapter{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}%
\Cref{table_t4t:languagecomparison} summarises the differences between the \gls{CLEAN} \gls{IOT} \gls{EDSL} and their host language.
The restrictions imposed by a resource-constrained execution environment on the tierless \gls{IOT} language are relatively minor. Moreover the \gls{MTASK} programming abstraction is broadly compatible with \gls{ITASK}. As a simple example compare the \gls{ITASK} and \gls{MTASK} temperature sensors in \cref{lst_t4t:itaskTempFull,lst_t4t:mtasktemp}. As a more realistic example, the \gls{MTASK} based \gls{CWS} smart campus implementation is similar to the \gls{ITASK} based \gls{CRS}, and requires less than 10\% additional code: 166 \gls{SLOC} compared with 155 \gls{SLOC} (\cref{table_t4t:multi}).
-Even with these restrictions, \gls{MTASK} programming is at a far higher level of abstraction than almost all bare metal languages, e.g.\ BIT, PICBIT, PICOBIT and Microscheme. That is \gls{MTASK} provides a set of higher order task combinators, shared distributed data stores, \etc. (\cref{sec_t4t:mtasks}). Moreover, it seems that common sensor node programs are readily expressed using \gls{MTASK}. In addition to the \gls{CWTS} and \gls{CWS} systems outlined here, other case studies include Arduino examples as well as some bigger tasks \citep{koopman_task-based_2018,lubbers_writing_2019,LubbersMIPRO}. We conclude that the programming of sensor tasks is well-supported by both \glspl{DSL}.
+Even with these restrictions, \gls{MTASK} programming is at a far higher level of abstraction than almost all bare metal languages, e.g.\ BIT, PICBIT, PICOBIT and Microscheme. That is \gls{MTASK} provides a set of higher order task combinators, shared distributed data stores, \etc. (\cref{sec_t4t:mtasks}). Moreover, it seems that common sensor node programs are readily expressed using \gls{MTASK}. In addition to the \gls{CWTS} and \gls{CWS} systems outlined here, other case studies include Arduino examples as well as some bigger tasks \citep{koopman_task-based_2018,lubbers_writing_2023,lubbers_multitasking_2019}. We conclude that the programming of sensor tasks is well-supported by both \glspl{DSL}.
\section{Conclusion}%
\label{sec_t4t:Conclusion}
repositories / phd-thesis.git / commitdiff