From: Mart Lubbers Date: Wed, 18 Jan 2023 15:03:06 +0000 (+0100) Subject: . X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=f281d83fd6978fe06aef38290808527ed970fd41;p=phd-thesis.git . --- diff --git a/asbook.tex b/asbook.tex index 5090d9f..a6e7816 100644 --- a/asbook.tex +++ b/asbook.tex @@ -4,7 +4,7 @@ \usepackage{pdfpages} \begin{document} -%\includepdf[landscape,booklet,pages={1-18}]{thesis.pdf}%chktex 29 chktex 8 +\includepdf[landscape,booklet,pages={1-22}]{thesis.pdf}%chktex 29 chktex 8 %\includepdf[landscape,booklet,pages={1-}]{top/4iot.pdf}%chktex 29 chktex 8 -\includepdf[pages={211,212}]{thesis.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 372ef50..df584ca 100644 --- a/concl/concl.tex +++ b/concl/concl.tex @@ -2,6 +2,8 @@ \input{subfilepreamble} +\setcounter{chapter}{9} + \begin{document} \input{subfileprefix} \chapter{Coda}% @@ -10,21 +12,29 @@ This chapter concludes the dissertation and reflects on the work. \end{chapterabstract} \section{Reflections} -Programming \gls{IOT} systems is classically complex.\todo{chap\-ter\-ab\-stract weg?} -Traditionally, on each layer of the system, different computers, hardware architectures, programming languages, programming paradigms, and abstraction levels are required. -All these factiors generating a lot of semantic friction. +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. +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. +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. -\Gls{TOP} has shown to provide a suitable programming paradigm that allows the declarative specification of exactly such systems. +\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 sheds light on orchestrating complete \gls{IOT} system using \gls{TOP}, specifically filling in the knowledge gap for edge devices in three episodes. +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. -\Cref{prt:dsl} presented two novel techniques for embedding \glspl{DSL} in \gls{FP} languages. -The novel classy deep embedding technique allows extension of a deeply embedded \gls{DSL} both in language constructs and in language interpretations. -Furthermore, by using the structural information available at compile time, a lot of the boilerplate required to develop an interoperating \gls{IOT} system can be automatically and hence safely generated. +\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 \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. +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. -It shows that when the \gls{DSL} is carefully designed, and domain-specific knowledge is embedded in the execution platform, it is possible to create a language that offers the same abstraction level as \gls{ITASK} provides on the server. 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:tvt} qualitatively and quantitatively compared traditional \gls{IOT} system programming, tiered programming, to the tierless programming. diff --git a/top/finale.tex b/top/finale.tex index 9caa86e..629a797 100644 --- a/top/finale.tex +++ b/top/finale.tex @@ -163,7 +163,7 @@ Traditional implementations of general purpose functional languages have high me There have been many efforts to create a general purpose functional language that does fit in small memory environments, albeit with some concessions. For example, there has been a history of creating tiny Scheme implementations for specific microcontrollers. It started with BIT \citep{dube_bit:_2000} that only required \qty{64}{\kibi\byte} of memory, followed by {PICBIT} \citep{feeley_picbit:_2003} and {PICOBIT} \citep{st-amour_picobit:_2009} that lowered the memory requirements even more. -\Citep{suchocki_microscheme:_2015} created Microscheme, a functional language targeting \gls{ARDUINO} compatible microcontrollers. +\Citet{suchocki_microscheme:_2015} created Microscheme, a functional language targeting \gls{ARDUINO} compatible microcontrollers. The {*BIT} languages all compile to assembly while Microscheme compiles to \gls{CPP}, heavily supported by \gls{CPP} lambdas available even on \gls{ARDUINO} AVR targets. An interpreted Lisp implementation called uLisp also exists that runs on microcontrollers with as small as the \gls{ARDUINO} {UNO} \citep{johnson-davies_lisp_2020}.