From: Mart Lubbers Date: Thu, 2 Feb 2023 14:52:50 +0000 (+0100) Subject: updates X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=b6db6f555ad33c9b0b6ea958b5319b32365018dd;p=phd-thesis.git updates --- diff --git a/asbook.tex b/asbook.tex index 5e6301d..b320532 100644 --- a/asbook.tex +++ b/asbook.tex @@ -4,7 +4,7 @@ \usepackage{pdfpages} \begin{document} -%\includepdf[landscape,booklet,pages={1-22}]{thesis.pdf}%chktex 29 chktex 8 -\includepdf[landscape,booklet,pages={1-}]{concl/concl.pdf}%chktex 29 chktex 8 +%\includepdf[landscape,booklet,pages={69-128}]{thesis.pdf}%chktex 29 chktex 8 +\includepdf[landscape,booklet,pages={3-}]{top/lang.pdf}%chktex 29 chktex 8 %\includepdf[pages={211,212}]{thesis.pdf}%chktex 29 chktex 8 \end{document} diff --git a/concl/concl.tex b/concl/concl.tex index cfbb92a..17a7828 100644 --- a/concl/concl.tex +++ b/concl/concl.tex @@ -8,57 +8,85 @@ \input{subfileprefix} \chapter{Coda}% \label{chp:conclusion}% +\ifSubfilesClassLoaded{\glsunsetall}{}% \begin{chapterabstract} This chapter concludes the dissertation and reflects on the work. \end{chapterabstract} \section{Reflections} -\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 dissertation shed light on orchestrating complete \gls{IOT} systems using \gls{TOP}. + +The term \gls{IOT} refers to the interconnected network of physical devices that are connected to each other and the internet. +The edge, or perception, layer of an \gls{IOT} systems is often powered by microcontrollers. +These small and cheap computers do not have powerful hardware but are energy efficient and support many sensors and actuators. +While 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 \gls{IOT} systems is very complex because each layer of the system is built with different computers, hardware architectures, programming languages, programming paradigms, and abstraction levels. This generates a lot of semantic friction. 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 a full-fledged \gls{TOP} system such as \gls{ITASK}. -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. -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. +The dissertation is structured as a purely functional rhapsody in three episodes. +It shows different techniques that aid crafting the tools required, i.e.\ creating the programming languages. +Then it shows the tool, \gls{MTASK}, a \gls{TOP} system for \gls{IOT} edge devices. +Finally it compares how this tool compares to existing tools. + +\subsection{Tool craft} +First some techniques for tool crafting are presented in \cref{prt:dsl} that are useful for creating \gls{TOP} languages for \gls{IOT} edge devices. +It presents two novel techniques for embedding \glspl{DSL} in \gls{FP} languages: +Classy deep embedding is a novel \gls{EDSL} embedding technique. 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 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. + +When embedding a \gls{DSL} in a language, much, but not all, of the machinery is inherited +For example, data types are not automatically useable in the \gls{DSL} because the interfaces such as constructors, deconstructors and constructor predicates 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} contains a complete overview of the \gls{MTASK} system: its design, integration with \gls{ITASK}, implementation, and green computing facilities. +\subsection{Tools} +General-purpose \gls{TOP} systems cannot run on edge devices due to their sizeable hardware requirements. +However, using advanced \gls{DSL} embedding techniques, \glspl{DSL} can be created that can be executed on edge devices while maintaining the high abstraction level. +By embedding domain-specific knowledge into the language and execution platform, and leaving out general-purpose functionality \gls{TOP} languages can be made suitable for edge devices. + +\Cref{prt:top} contains a complete overview of such a tool: the \gls{MTASK} system. +Its design, integration with \gls{ITASK}, implementation, and green computing facilities are shown. The \gls{MTASK} language is a unique domain-specific \gls{TOP} \gls{EDSL} designed system for edge devices. The \gls{MTASK} 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?} -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. +\subsection{Comparison} +Previous episodes show that it is possible to program all layers of an \gls{IOT} systems using \gls{TOP}. +Using tierless programming, many issues that arise with tiered programming are mitigated. +This has already been observed in web applications. +The question whether this novel approach to programming tiered systems also reduces the develop grief is answered in \cref{prt:tvt}. +This episode presents a four-way qualitatively and quantitatively comparison of the following systems: +\begin{enumerate*} + \item \gls{PRS}, a tiered system based on resource-rich edge devices powered by \gls{PYTHON}; + \item \gls{PWS}, a tiered system based on resource-constrained edge devices by \gls{MICROPYTHON}; + \item \gls{CRS}, a tierless system based on resource-rich edge devices powered by \gls{ITASK}; + \item \gls{CWS}, a tierless system based on resource-constrained edge devices powered by \imtask{}. +\end{enumerate*} + +This comparison shows that when using a programming paradigm that is available both for resource-rich and resource-constrained edge devices, there is little difference in developer grief. +On the other hand, using a tierless system compared to a tiered system reduces the developer grief significantly. -However, it is not a silver bullet. -However, it has some disadvantages as well. -Tierless languages are novel, and hence lacking tooling and community support. -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. +Using either \imtask{} when dealing with resource-constrained devices such as microcontrollers or just \gls{ITASK} for all layers all layers of the entire \gls{IOT} system are specified in a single source, the same strong type system, and similar high abstraction level. +The tierless approach results in fewer \gls{SLOC}, files, programming languages and programming paradigms. +All code is simultaneously checked by a single compiler, reducing interoperability problems. +Furthermore, all communication and integration is automatically generated, reducing interoperability issues even more. +% +However, it is not a silver bullet, there are some disadvantages as well. +Tierless languages are novel, and hence often lack tooling and community support. +They contain high-level tierless abstractions that the programmer has to master. +The low-level specific semantics of the final application may become more difficult to distill from the specification. +Finally, the system is more monolithic compared to tiered approaches. Changing components within the system is easy if it already is supported in the \gls{EDSL}. 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}. diff --git a/top/lang.tex b/top/lang.tex index d0945c9..2c5cb70 100644 --- a/top/lang.tex +++ b/top/lang.tex @@ -9,7 +9,7 @@ \chapter{The \texorpdfstring{\gls{MTASK}}{mTask} language}%\texorpdfstring{\glsxtrshort{DSL}}{DSL}}% \label{chp:mtask_dsl} \begin{chapterabstract} - \noindent This chapter introduces the \gls{TOP} language \gls{MTASK} language by: + This chapter introduces the \gls{TOP} language \gls{MTASK} language by: \begin{itemize} \item introducing the setup of the \gls{EDSL}; \item describing briefly the various interpretations;