\ifSubfilesClassLoaded{\appendix\setcounter{chapter}{2}}{}
\chapter{Bytecode instruction set}%
\label{chp:bytecode_instruction_set}%
-This appendix describeds the semantics of the byte code instruction set of \gls{MTASK} (see \cref{chp:implementation}).
+Tasks in \gls{MTASK} are compiled at run time to byte code.
+This byte code is evaluated using the interpreter.
+The result of this evaluation is a task tree.
+Subsequently, this task tree is rewritten until a stable value is observed.
+This appendix describes the semantics of the byte code instruction set of \gls{MTASK} (see \cref{chp:implementation}).
The byte code instructions are of variable length and automatically encoded and decoded using generic programming (see \cref{sec:ccodegen}).
-\Cref{tbl:bc_notation} shows the notation convention.
+\Cref{tbl:bc_notation} shows the notational convention of the variables used in the table.
\Cref{tbl:instr_task} shows the semantics of all major byte code instructions, shorthand instructions and auxiliary peripherals have been omitted for brevity but have the analogous semantics as their counterparts.
\begin{table}
\clearpage
\section{Syntax}
\lstset{basicstyle=\tt\footnotesize}
-\begin{longtable}{p{.45\linewidth}p{.5\linewidth}}
+\begin{longtable}{p{.46\linewidth}p{.46\linewidth}}
\caption[]{Syntactical differences between \gls{CLEAN} and \gls{HASKELL}.}%
\label{tbl:syn_clean_haskell}\\
\toprule
\gls{CLEAN} & \gls{HASKELL}\\
\midrule
\endfirsthead%
- \caption[]{(continued)}\\
+ \caption[]{Syntactical differences between \gls{CLEAN} and \gls{HASKELL}. (continued)}\\
\toprule
\gls{CLEAN} & \gls{HASKELL}\\
\midrule
\input{subfilepreamble}
-
\begin{document}
\input{subfileprefix}
\ifSubfilesClassLoaded{\appendix\setcounter{chapter}{1}}{}
doi = {10.1145/2370776.2370801},
abstract = {Task-Oriented Programming (TOP) is a novel programming paradigm for the construction of distributed systems where users work together on the internet. When multiple users collaborate, they need to interact with each other frequently. TOP supports the definition of tasks that react to the progress made by others. With TOP, complex multi-user interactions can be programmed in a declarative style just by defining the tasks that have to be accomplished, thus eliminating the need to worry about the implementation detail that commonly frustrates the development of applications for this domain. TOP builds on four core concepts: tasks that represent computations or work to do which have an observable value that may change over time, data sharing enabling tasks to observe each other while the work is in progress, generic type driven generation of user interaction, and special combinators for sequential and parallel task composition. The semantics of these core concepts is defined in this paper. As an example we present the iTask3 framework, which embeds TOP in the functional programming language Clean.},
booktitle = {Proceedings of the 14th {Symposium} on {Principles} and {Practice} of {Declarative} {Programming}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Plasmeijer, Rinus and Lijnse, Bas and Michels, Steffen and Achten, Peter and Koopman, Pieter},
year = {2012},
note = {event-place: Leuven, Belgium},
doi = {10.1145/237721.237792},
abstract = {We revisit the work of Paterson and of Meijer \& Hutton, which describes how to construct catamorphisms for recursive datatype definitions that embed contravariant occurrences of the type being defined. Their construction requires, for each catamorphism, the definition of an anamorphism that has an inverse-like relationship to that catamorphism. We present an alternative construction, which replaces the stringent requirement that an inverse anamorphism be defined for each catamorphism with a more lenient restriction. The resulting construction has a more efficient implementation than that of Paterson, Meijer, and Hutton and the relevant restriction can be enforced by a Hindley-Milner type inference algorithm. We provide numerous examples illustrating our method.},
booktitle = {Proceedings of the 23rd {ACM} {SIGPLAN}-{SIGACT} {Symposium} on {Principles} of {Programming} {Languages}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Fegaras, Leonidas and Sheard, Tim},
year = {1996},
note = {event-place: St. Petersburg Beach, Florida, USA},
doi = {10.1145/53990.54010},
abstract = {We describe motivation, design, use, and implementation of higher-order abstract syntax as a central representation for programs, formulas, rules, and other syntactic objects in program manipulation and other formal systems where matching and substitution or unification are central operations. Higher-order abstract syntax incorporates name binding information in a uniform and language generic way. Thus it acts as a powerful link integrating diverse tools in such formal environments. We have implemented higher-order abstract syntax, a supporting matching and unification algorithm, and some clients in Common Lisp in the framework of the Ergo project at Carnegie Mellon University.},
booktitle = {Proceedings of the {ACM} {SIGPLAN} 1988 {Conference} on {Programming} {Language} {Design} and {Implementation}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Pfenning, F. and Elliott, C.},
year = {1988},
note = {event-place: Atlanta, Georgia, USA},
doi = {10.1145/1411204.1411226},
abstract = {We present parametric higher-order abstract syntax (PHOAS), a new approach to formalizing the syntax of programming languages in computer proof assistants based on type theory. Like higher-order abstract syntax (HOAS), PHOAS uses the meta language's binding constructs to represent the object language's binding constructs. Unlike HOAS, PHOAS types are definable in general-purpose type theories that support traditional functional programming, like Coq's Calculus of Inductive Constructions. We walk through how Coq can be used to develop certified, executable program transformations over several statically-typed functional programming languages formalized with PHOAS; that is, each transformation has a machine-checked proof of type preservation and semantic preservation. Our examples include CPS translation and closure conversion for simply-typed lambda calculus, CPS translation for System F, and translation from a language with ML-style pattern matching to a simpler language with no variable-arity binding constructs. By avoiding the syntactic hassle associated with first-order representation techniques, we achieve a very high degree of proof automation.},
booktitle = {Proceedings of the 13th {ACM} {SIGPLAN} {International} {Conference} on {Functional} {Programming}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Chlipala, Adam},
year = {2008},
note = {event-place: Victoria, BC, Canada},
language = {English},
urldate = {2021-02-24},
publisher = {Release},
- author = {{GHC Team}},
+ author = {{{{{GHC Team}}}}},
year = {2021},
file = {GHC Team - 2021 - GHC User’s Guide Documentation.pdf:/home/mrl/.local/share/zotero/storage/87ZT5VXL/GHC Team - 2021 - GHC User’s Guide Documentation.pdf:application/pdf},
}
language = {English},
urldate = {2021-02-24},
publisher = {Release},
- author = {{GHC Team}},
+ author = {{{{{GHC Team}}}}},
year = {2021},
}
doi = {10.1145/1140335.1140352},
abstract = {The problem of supporting the modular extensibility of both data and functions in one programming language at the same time is known as the expression problem. Functional languages traditionally make it easy to add new functions, but extending data (adding new data constructors) requires modifying existing code. We present a semantically and syntactically lightweight variant of open data types and open functions as a solution to the expression problem in the Haskell language. Constructors of open data types and equations of open functions may appear scattered throughout a program with several modules. The intended semantics is as follows: the program should behave as if the data types and functions were closed, defined in one place. The order of function equations is determined by best-fit pattern matching, where a specific pattern takes precedence over an unspecific one. We show that our solution is applicable to the expression problem, generic programming, and exceptions. We sketch two implementations: a direct implementation of the semantics, and a scheme based on mutually recursive modules that permits separate compilation},
booktitle = {Proceedings of the 8th {ACM} {SIGPLAN} {International} {Conference} on {Principles} and {Practice} of {Declarative} {Programming}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Löh, Andres and Hinze, Ralf},
year = {2006},
note = {event-place: Venice, Italy},
doi = {10.1145/289423.289457},
abstract = {In this paper we explain how recursion operators can be used to structure and reason about program semantics within a functional language. In particular, we show how the recursion operator fold can be used to structure denotational semantics, how the dual recursion operator unfold can be used to structure operational semantics, and how algebraic properties of these operators can be used to reason about program semantics. The techniques are explained with the aid of two main examples, the first concerning arithmetic expressions, and the second concerning Milner's concurrent language CCS. The aim of the paper is to give functional programmers new insights into recursion operators, program semantics, and the relationships between them.},
booktitle = {Proceedings of the {Third} {ACM} {SIGPLAN} {International} {Conference} on {Functional} {Programming}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Hutton, Graham},
year = {1998},
note = {event-place: Baltimore, Maryland, USA},
doi = {10.1145/2103786.2103795},
abstract = {Static type systems strive to be richly expressive while still being simple enough for programmers to use. We describe an experiment that enriches Haskell's kind system with two features promoted from its type system: data types and polymorphism. The new system has a very good power-to-weight ratio: it offers a significant improvement in expressiveness, but, by re-using concepts that programmers are already familiar with, the system is easy to understand and implement.},
booktitle = {Proceedings of the 8th {ACM} {SIGPLAN} {Workshop} on {Types} in {Language} {Design} and {Implementation}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Yorgey, Brent A. and Weirich, Stephanie and Cretin, Julien and Peyton Jones, Simon and Vytiniotis, Dimitrios and Magalhães, José Pedro},
year = {2012},
note = {event-place: Philadelphia, Pennsylvania, USA},
doi = {10.1145/1596638.1596644},
abstract = {Higher-order abstract syntax provides a convenient way of embedding domain-specific languages, but is awkward to analyse and manipulate directly. We explore the boundaries of higher-order abstract syntax. Our key tool is the unembedding of embedded terms as de Bruijn terms, enabling intensional analysis. As part of our solution we present techniques for separating the definition of an embedded program from its interpretation, giving modular extensions of the embedded language, and different ways to encode the types of the embedded language.},
booktitle = {Proceedings of the 2nd {ACM} {SIGPLAN} {Symposium} on {Haskell}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Atkey, Robert and Lindley, Sam and Yallop, Jeremy},
year = {2009},
note = {event-place: Edinburgh, Scotland},
@phdthesis{alimarine_generic_2005,
address = {Nijmegen},
- type = {{PhD}},
+ type = {PhD Thesis},
title = {Generic {Functional} {Programming}},
language = {en},
school = {Radboud University},
@inproceedings{wand_continuation-based_1980,
address = {Stanford University, California, United States},
title = {Continuation-based multiprocessing},
- url = {http://portal.acm.org/citation.cfm?doid=800087.802786},
doi = {10.1145/800087.802786},
abstract = {Any multiprocessing facility must include three features: elementary exclusion, data protection, and process saving. While elementary exclusion must rest on some hardware facility (e.g., a test-and-set instruction), the other two requirements are fulfilled by features already present in applicative languages. Data protection may be obtained through the use of procedures (closures or funargs), and process saving may be obtained through the use of the catch operator. The use of catch, in particular, allows an elegant treatment of process saving.},
language = {en},
doi = {10.1145/1291201.1291211},
abstract = {Quasiquoting allows programmers to use domain specific syntax to construct program fragments. By providing concrete syntax for complex data types, programs become easier to read, easier to write, and easier to reason about and maintain. Haskell is an excellent host language for embedded domain specific languages, and quasiquoting ideally complements the language features that make Haskell perform so well in this area. Unfortunately, until now no Haskell compiler has provided support for quasiquoting. We present an implementation in GHC and demonstrate that by leveraging existing compiler capabilities, building a full quasiquoter requires little more work than writing a parser. Furthermore, we provide a compile-time guarantee that all quasiquoted data is type-correct.},
booktitle = {Proceedings of the {ACM} {SIGPLAN} {Workshop} on {Haskell} {Workshop}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Mainland, Geoffrey},
year = {2007},
note = {event-place: Freiburg, Germany},
doi = {10.1145/1411286.1411300},
abstract = {Monads as an organizing principle for programming and semantics are notoriously difficult to grasp, yet they are a central and powerful abstraction in Haskell. This paper introduces a domain-specific language, MonadLab, that simplifies the construction of monads, and describes its implementation in Template Haskell. MonadLab makes monad construction truly first class, meaning that arcane theoretical issues with respect to monad transformers are completely hidden from the programmer. The motivation behind the design of MonadLab is to make monadic programming in Haskell simpler while providing a tool for non-Haskell experts that will assist them in understanding this powerful abstraction.},
booktitle = {Proceedings of the {First} {ACM} {SIGPLAN} {Symposium} on {Haskell}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Kariotis, Pericles S. and Procter, Adam M. and Harrison, William L.},
year = {2008},
note = {event-place: Victoria, BC, Canada},
doi = {10.1145/581690.581691},
abstract = {We propose a new extension to the purely functional programming language Haskell that supports compile-time meta-programming. The purpose of the system is to support the algorithmic construction of programs at compile-time.The ability to generate code at compile time allows the programmer to implement such features as polytypic programs, macro-like expansion, user directed optimization (such as inlining), and the generation of supporting data structures and functions from existing data structures and functions.Our design is being implemented in the Glasgow Haskell Compiler, ghc.},
booktitle = {Proceedings of the 2002 {ACM} {SIGPLAN} {Workshop} on {Haskell}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Sheard, Tim and Peyton Jones, Simon},
year = {2002},
note = {event-place: Pittsburgh, Pennsylvania},
doi = {10.1145/2364506.2364509},
abstract = {Generic programming allows the concise expression of algorithms that would otherwise require large amounts of handwritten code. A number of such systems have been developed over the years, but a common drawback of these systems is poor runtime performance relative to handwritten, non-generic code. Generic-programming systems vary significantly in this regard, but few consistently match the performance of handwritten code. This poses a dilemma for developers. Generic-programming systems offer concision but cost performance. Handwritten code offers performance but costs concision.This paper explores the use of Template Haskell to achieve the best of both worlds. It presents a generic-programming system for Haskell that provides both the concision of other generic-programming systems and the efficiency of handwritten code. Our system gives the programmer a high-level, generic-programming interface, but uses Template Haskell to generate efficient, non-generic code that outperforms existing generic-programming systems for Haskell.This paper presents the results of benchmarking our system against both handwritten code and several other generic-programming systems. In these benchmarks, our system matches the performance of handwritten code while other systems average anywhere from two to twenty times slower.},
booktitle = {Proceedings of the 2012 {Haskell} {Symposium}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Adams, Michael D. and DuBuisson, Thomas M.},
year = {2012},
note = {event-place: Copenhagen, Denmark},
isbn = {0-89791-200-4},
doi = {10.1145/319838.319859},
booktitle = {Proceedings of the 1986 {ACM} {Conference} on {LISP} and {Functional} {Programming}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Kohlbecker, Eugene and Friedman, Daniel P. and Felleisen, Matthias and Duba, Bruce},
year = {1986},
note = {event-place: Cambridge, Massachusetts, USA},
doi = {10.1145/604174.604179},
abstract = {We describe a design pattern for writing programs that traverse data structures built from rich mutually-recursive data types. Such programs often have a great deal of "boilerplate" code that simply walks the structure, hiding a small amount of "real" code that constitutes the reason for the traversal.Our technique allows most of this boilerplate to be written once and for all, or even generated mechanically, leaving the programmer free to concentrate on the important part of the algorithm. These generic programs are much more adaptive when faced with data structure evolution because they contain many fewer lines of type-specific code.Our approach is simple to understand, reasonably efficient, and it handles all the data types found in conventional functional programming languages. It makes essential use of rank-2 polymorphism, an extension found in some implementations of Haskell. Further it relies on a simple type-safe cast operator.},
booktitle = {Proceedings of the 2003 {ACM} {SIGPLAN} {International} {Workshop} on {Types} in {Languages} {Design} and {Implementation}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Lämmel, Ralf and Peyton Jones, Simon},
year = {2003},
note = {event-place: New Orleans, Louisiana, USA},
doi = {10.1145/2658761.2658770},
abstract = {This paper presents a library called LibDSL that helps the implementer of an embedded domain specific language (EDSL) effectively develop it in D language. The LibDSL library accepts as input some kinds of “specifications” of the EDSL that the implementer is going to develop and a D program within which an EDSL source program written by the user is embedded. It produces the front-end code of an LALR parser for the EDSL program and back-end code of the execution engine. LibDSL is able to produce two kinds of execution engines, namely compiler-based and interpreter-based engines, either of which the user can properly choose depending on whether an EDSL program is known at compile time or not. We have implemented the LibDSL system by using template metaprogramming and other advanced facilities such as compile-time function execution of D language. EDSL programs developed by means of LibDSL have a nice integrativeness with the host language.},
booktitle = {Proceedings of the 2014 {International} {Conference} on {Generative} {Programming}: {Concepts} and {Experiences}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Shioda, Masato and Iwasaki, Hideya and Sato, Shigeyuki},
year = {2014},
note = {event-place: Västerås, Sweden},
doi = {10.1145/2034675.2034689},
abstract = {We present a novel method of embedding context-free grammars in Haskell, and to automatically generate parsers and pretty-printers from them. We have implemented this method in a library called BNFC-meta (from the BNF Converter, which it is built on). The library builds compiler front ends using metaprogramming instead of conventional code generation. Parsers are built from labelled BNF grammars that are defined directly in Haskell modules. Our solution combines features of parser generators (static grammar checks, a highly specialised grammar DSL) and adds several features that are otherwise exclusive to combinatory libraries such as the ability to reuse, parameterise and generate grammars inside Haskell.To allow writing grammars in concrete syntax, BNFC-meta provides a quasi-quoter that can parse grammars (embedded in Haskell files) at compile time and use metaprogramming to replace them with their abstract syntax. We also generate quasi-quoters so that the languages we define with BNFC-meta can be embedded in the same way. With a minimal change to the grammar, we support adding anti-quotation to the generated quasi-quoters, which allows users of the defined language to mix concrete and abstract syntax almost seamlessly. Unlike previous methods of achieving anti-quotation, the method used by BNFC-meta is simple, efficient and avoids polluting the abstract syntax types.},
booktitle = {Proceedings of the 4th {ACM} {Symposium} on {Haskell}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Duregård, Jonas and Jansson, Patrik},
year = {2011},
note = {event-place: Tokyo, Japan},
doi = {10.1145/2633357.2633361},
abstract = {Haskell, as implemented in the Glasgow Haskell Compiler (GHC), is enriched with many extensions that support type-level programming, such as promoted datatypes, kind polymorphism, and type families. Yet, the expressiveness of the type-level language remains limited. It is missing many features present at the term level, including case expressions, anonymous functions, partially-applied functions, and let expressions. In this paper, we present an algorithm - with a proof of correctness - to encode these term-level constructs at the type level. Our approach is automated and capable of promoting a wide array of functions to type families. We also highlight and discuss those term-level features that are not promotable. In so doing, we offer a critique on GHC's existing type system, showing what it is already capable of and where it may want improvement.We believe that delineating the mismatch between GHC's term level and its type level is a key step toward supporting dependently typed programming.},
booktitle = {Proceedings of the 2014 {ACM} {SIGPLAN} {Symposium} on {Haskell}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Eisenberg, Richard A. and Stolarek, Jan},
year = {2014},
note = {event-place: Gothenburg, Sweden},
doi = {10.1145/3310232.3310235},
abstract = {In this paper, we present an embedding of attribute grammars in Haskell, that is both modular and type-safe, while providing the user with domain specific error messages.Our approach involves to delay part of the safety checks to runtime. When a grammar is correct, we are able to extract a function that can be run without expecting any runtime error related to the EDSL.},
booktitle = {Proceedings of the 30th {Symposium} on {Implementation} and {Application} of {Functional} {Languages}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Viera, Marcos and Balestrieri, Florent and Pardo, Alberto},
year = {2018},
note = {event-place: Lowell, MA, USA},
doi = {10.1145/2364506.2364524},
abstract = {Though Haskell is predominantly type-safe, implementations contain a few loopholes through which code can bypass typing and module encapsulation. This paper presents Safe Haskell, a language extension that closes these loopholes. Safe Haskell makes it possible to confine and safely execute untrusted, possibly malicious code. By strictly enforcing types, Safe Haskell allows a variety of different policies from API sandboxing to information-flow control to be implemented easily as monads. Safe Haskell is aimed to be as unobtrusive as possible. It enforces properties that programmers tend to meet already by convention. We describe the design of Safe Haskell and an implementation (currently shipping with GHC) that infers safety for code that lies in a safe subset of the language. We use Safe Haskell to implement an online Haskell interpreter that can securely execute arbitrary untrusted code with no overhead. The use of Safe Haskell greatly simplifies this task and allows the use of a large body of existing code and tools.},
booktitle = {Proceedings of the 2012 {Haskell} {Symposium}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Terei, David and Marlow, Simon and Peyton Jones, Simon and Mazières, David},
year = {2012},
note = {event-place: Copenhagen, Denmark},
doi = {10.1145/2628136.2628138},
abstract = {A domain-specific language can be implemented by embedding within a general-purpose host language. This embedding may be deep or shallow, depending on whether terms in the language construct syntactic or semantic representations. The deep and shallow styles are closely related, and intimately connected to folds; in this paper, we explore that connection.},
booktitle = {Proceedings of the 19th {ACM} {SIGPLAN} {International} {Conference} on {Functional} {Programming}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Gibbons, Jeremy and Wu, Nicolas},
year = {2014},
note = {event-place: Gothenburg, Sweden},
doi = {10.1145/1088348.1088358},
abstract = {A type-indexed function is a function that is defined for each member of some family of types. Haskell's type class mechanism provides collections of open type-indexed functions, in which the indexing family can be extended by defining a new type class instance but the collection of functions is fixed. The purpose of this paper is to present TypeCase: a design pattern that allows the definition of closed type-indexed functions, in which the index family is fixed but the collection of functions is extensible. It is inspired by Cheney and Hinze's work on lightweight approaches to generic programming. We generalise their techniques as a design pattern. Furthermore, we show that type-indexed functions with type-indexed types, and consequently generic functions with generic types, can also be encoded in a lightweight manner, thereby overcoming one of the main limitations of the lightweight approaches.},
booktitle = {Proceedings of the 2005 {ACM} {SIGPLAN} {Workshop} on {Haskell}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Oliveira, Bruno C. d. S. and Gibbons, Jeremy},
year = {2005},
note = {event-place: Tallinn, Estonia},
doi = {10.1145/237721.237729},
abstract = {We study an extension of the Hindley/Milner system with explicit type scheme annotations and type declarations. The system can express polymorphic function arguments, user-defined data types with abstract components, and structure types with polymorphic fields. More generally, all programs of the polymorphic lambda calculus can be encoded by a translation between typing derivations. We show that type reconstruction in this system can be reduced to the decidable problem of first-order unification under a mixed prefix.},
booktitle = {Proceedings of the 23rd {ACM} {SIGPLAN}-{SIGACT} {Symposium} on {Principles} of {Programming} {Languages}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Odersky, Martin and Läufer, Konstantin},
year = {1996},
note = {event-place: St. Petersburg Beach, Florida, USA},
doi = {10.1145/2847538.2847541},
abstract = {We describe a new approach to implementing Domain-Specific Languages(DSLs), called Quoted DSLs (QDSLs), that is inspired by two old ideas:quasi-quotation, from McCarthy's Lisp of 1960, and the subformula principle of normal proofs, from Gentzen's natural deduction of 1935. QDSLs reuse facilities provided for the host language, since host and quoted terms share the same syntax, type system, and normalisation rules. QDSL terms are normalised to a canonical form, inspired by the subformula principle, which guarantees that one can use higher-order types in the source while guaranteeing first-order types in the target, and enables using types to guide fusion. We test our ideas by re-implementing Feldspar, which was originally implemented as an Embedded DSL (EDSL), as a QDSL; and we compare the QDSL and EDSL variants. The two variants produce identical code.},
booktitle = {Proceedings of the 2016 {ACM} {SIGPLAN} {Workshop} on {Partial} {Evaluation} and {Program} {Manipulation}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Najd, Shayan and Lindley, Sam and Svenningsson, Josef and Wadler, Philip},
year = {2016},
note = {event-place: St. Petersburg, FL, USA},
doi = {10.1145/331960.331977},
abstract = {Domain-specific embedded languages (DSELs) expressed in higher-order, typed (HOT) languages provide a composable framework for domain-specific abstractions. Such a framework is of greater utility than a collection of stand-alone domain-specific languages. Usually, embedded domain specific languages are build on top of a set of domain specific primitive functions that are ultimately implemented using some form of foreign function call. We sketch a general design pattern/or embedding client-server style services into Haskell using a domain specific embedded compiler for the server's source language. In particular we apply this idea to implement Haskell/DB, a domain specific embdedded compiler that dynamically generates of SQL queries from monad comprehensions, which are then executed on an arbitrary ODBC database server.},
booktitle = {Proceedings of the 2nd {Conference} on {Domain}-{Specific} {Languages}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Leijen, Daan and Meijer, Erik},
year = {2000},
note = {event-place: Austin, Texas, USA},
doi = {10.1145/3412932.3412941},
abstract = {More and more applications rely on the safe execution of code unknown at compile-time, for example in the implementation of web browsers and plugin systems. Furthermore, these applications usually require some form of communication between the added code and its embedder, and hence a communication channel must be set up in which values are serialized and deserialized. This paper shows that in a functional programming language we can solve these two problems at once, if we realize that the execution of extra code is nothing more than the deserialization of a value which happens to be a function. To demonstrate this, we describe the implementation of a serialization library for the language Clean, which internally uses an interpreter to evaluate added code in a separate, sandboxed environment. Remarkable is that despite the conceptual asymmetry between "host" and "interpreter", lazy interworking must be implemented in a highly symmetric fashion, much akin to distributed systems. The library interworks on a low level with the native Clean program, but has been implemented without any changes to the native runtime system. It can therefore easily be ported to other programming languages.We can use the same technique in the context of the web, where we want to be able to share possibly lazy values between a server and a client. In this case the interpreter runs in WebAssembly in the browser and communicates seamlessly with the server, written in Clean. We use this in the iTasks web framework to handle communication and offload computations to the client to reduce stress on the server-side. Previously, this framework cross-compiled the Clean source code to JavaScript and used JSON for communication. The interpreter has a more predictable and better performance, and integration is much simpler because it interworks on a lower level with the web server.},
booktitle = {Proceedings of the 31st {Symposium} on {Implementation} and {Application} of {Functional} {Languages}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Staps, Camil and van Groningen, John and Plasmeijer, Rinus},
year = {2019},
note = {event-place: Singapore, Singapore},
doi = {10.1145/3354166.3354182},
abstract = {Software that models how people work is omnipresent in today's society. Current languages and frameworks often focus on usability by non-programmers, sacrificing flexibility and high level abstraction. Task-oriented programming (TOP) is a programming paradigm that aims to provide the desired level of abstraction while still being expressive enough to describe real world collaboration. It prescribes a declarative programming style to specify multi-user workflows. Workflows can be higher-order. They communicate through typed values on a local and global level. Such specifications can be turned into interactive applications for different platforms, supporting collaboration during execution. TOP has been around for more than a decade, in the forms of iTasks and mTasks, which are tailored for real-world usability. So far, it has not been given a formalisation which is suitable for formal reasoning.In this paper we give a description of the TOP paradigm and then decompose its rich features into elementary language elements, which makes them suitable for formal treatment. We use the simply typed lambda-calculus, extended with pairs and references, as a base language. On top of this language, we develop TopHat, a language for modular interactive workflows. We describe TopHat by means of a layered semantics. These layers consist of multiple big-step evaluations on expressions, and two labelled transition systems, handling user inputs.With TopHat we prepare a way to formally reason about TOP languages and programs. This approach allows for comparison with other work in the field. We have implemented the semantic rules of TopHat in Haskell, and the task layer on top of the iTasks framework. This shows that our approach is feasible, and lets us demonstrate the concepts by means of illustrative case studies. TOP has been applied in projects with the Dutch coast guard, tax office, and navy. Our work matters because formal program verification is important for mission-critical software, especially for systems with concurrency.},
booktitle = {Proceedings of the 21st {International} {Symposium} on {Principles} and {Practice} of {Declarative} {Programming}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Steenvoorden, Tim and Naus, Nico and Klinik, Markus},
year = {2019},
note = {event-place: Porto, Portugal},
doi = {10.1145/581478.581494},
abstract = {Even when programming in a statically typed language we every now and then encounter statically untypable values; such values result from interpreting values or from communicating with the outside world. To cope with this problem most languages include some form of dynamic types. It may be that the core language has been explicitly extended with such a type, or that one is allowed to live dangerously by using functions like unsafeCoerce. We show how, by a careful use of existentially and universally quantified types, one may achievem the same effect, without extending the language with new or unsafe features. The techniques explained are universally applicable, provided the core language is expressive enough; this is the case for the common implementations of Haskell. The techniques are used in the description of a type checking compiler that, starting from an expression term, constructs a typed function representing the semantics of that expression. In this function the overhead associated with the type checking is only once being paid for; in this sense we have thus achieved static type checking.},
booktitle = {Proceedings of the {Seventh} {ACM} {SIGPLAN} {International} {Conference} on {Functional} {Programming}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Baars, Arthur I. and Swierstra, S. Doaitse},
year = {2002},
note = {event-place: Pittsburgh, PA, USA},
doi = {10.1145/158511.158524},
abstract = {We present a new model, based on monads, for performing input/output in a non-strict, purely functional language. It is composable, extensible, efficient, requires no extensions to the type system, and extends smoothly to incorporate mixed-language working and in-place array updates.},
booktitle = {Proceedings of the 20th {ACM} {SIGPLAN}-{SIGACT} {Symposium} on {Principles} of {Programming} {Languages}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Peyton Jones, Simon and Wadler, Philip},
year = {1993},
note = {event-place: Charleston, South Carolina, USA},
doi = {10.1145/3406088.3409021},
abstract = {Generic programming libraries have historically traded efficiency in return for convenience, and the generics-sop library is no exception. It offers a simple, uniform, representation of all datatypes precisely as a sum of products, making it easy to write generic functions. We show how to finally make generics-sop fast through the use of staging with Typed Template Haskell.},
booktitle = {Proceedings of the 13th {ACM} {SIGPLAN} {International} {Symposium} on {Haskell}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Pickering, Matthew and Löh, Andres and Wu, Nicolas},
year = {2020},
note = {event-place: Virtual Event, USA},
doi = {10.1145/2633628.2633634},
abstract = {We introduce the sum-of-products (SOP) view for datatype-generic programming (in Haskell). While many of the libraries that are commonly in use today represent datatypes as arbitrary combinations of binary sums and products, SOP reflects the structure of datatypes more faithfully: each datatype is a single n-ary sum, where each component of the sum is a single n-ary product. This representation turns out to be expressible accurately in GHC with today's extensions. The resulting list-like structure of datatypes allows for the definition of powerful high-level traversal combinators, which in turn encourage the definition of generic functions in a compositional and concise style. A major plus of the SOP view is that it allows to separate function-specific metadata from the main structural representation and recombining this information later.},
booktitle = {Proceedings of the 10th {ACM} {SIGPLAN} {Workshop} on {Generic} {Programming}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {de Vries, Edsko and Löh, Andres},
year = {2014},
note = {event-place: Gothenburg, Sweden},
doi = {10.1145/3331545.3342597},
abstract = {Cross-stage persistence is an essential aspect of multi-stage programming that allows a value defined in one stage to be available in another. However, difficulty arises when implicit information held in types, type classes and implicit parameters needs to be persisted. Without a careful treatment of such implicit information—which are pervasive in Haskell—subtle yet avoidable bugs lurk beneath the surface. This paper demonstrates that in multi-stage programming care must be taken when representing quoted terms so that important implicit information is kept in context and not discarded. The approach is formalised with a type-system, and an implementation in GHC is presented that fixes problems of the previous incarnation.},
booktitle = {Proceedings of the 12th {ACM} {SIGPLAN} {International} {Symposium} on {Haskell}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Pickering, Matthew and Wu, Nicolas and Kiss, Csongor},
year = {2019},
note = {event-place: Berlin, Germany},
doi = {10.1145/3546189.3549921},
abstract = {Liquid Haskell is a popular verifier for Haskell programs, leveraging the power of SMT solvers to ease users' burden of proof. However, this power does not come without a price: convincing Liquid Haskell that a program is correct often necessitates giving hints to the underlying solver, which can be a tedious and verbose process that sometimes requires intricate knowledge of Liquid Haskell's inner workings. In this paper, we present Liquid Proof Macros, an extensible metaprogramming technique and framework for simplifying the development of Liquid Haskell proofs. We describe how to leverage Template Haskell to generate Liquid Haskell proof terms, via a tactic-inspired DSL interface for more concise and user-friendly proofs, and we demonstrate the capabilities of this framework by automating a wide variety of proofs from an existing Liquid Haskell benchmark.},
booktitle = {Proceedings of the 15th {ACM} {SIGPLAN} {International} {Haskell} {Symposium}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Blanchette, Henry and Vazou, Niki and Lampropoulos, Leonidas},
year = {2022},
note = {event-place: Ljubljana, Slovenia},
doi = {10.1145/3546189.3549917},
abstract = {Haskell is a popular choice for hosting deeply embedded languages. A recurring challenge for these embeddings is how to seamlessly integrate user defined algebraic data types. In particular, one important, convenient, and expressive feature for creating and inspecting data—pattern matching—is not directly available on embedded terms. We present a novel technique, embedded pattern matching, which enables a natural and user friendly embedding of user defined algebraic data types into the embedded language, and allows programmers to pattern match on terms in the embedded language in much the same way they would in the host language.},
booktitle = {Proceedings of the 15th {ACM} {SIGPLAN} {International} {Haskell} {Symposium}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {McDonell, Trevor L. and Meredith, Joshua D. and Keller, Gabriele},
year = {2022},
note = {event-place: Ljubljana, Slovenia},
doi = {10.1145/3009837.3009900},
abstract = {Structure editors allow programmers to edit the tree structure of a program directly. This can have cognitive benefits, particularly for novice and end-user programmers. It also simplifies matters for tool designers, because they do not need to contend with malformed program text. This paper introduces Hazelnut, a structure editor based on a small bidirectionally typed lambda calculus extended with holes and a cursor. Hazelnut goes one step beyond syntactic well-formedness: its edit actions operate over statically meaningful incomplete terms. Naïvely, this would force the programmer to construct terms in a rigid "outside-in" manner. To avoid this problem, the action semantics automatically places terms assigned a type that is inconsistent with the expected type inside a hole. This meaningfully defers the type consistency check until the term inside the hole is finished. Hazelnut is not intended as an end-user tool itself. Instead, it serves as a foundational account of typed structure editing. To that end, we describe how Hazelnut's rich metatheory, which we have mechanized using the Agda proof assistant, serves as a guide when we extend the calculus to include binary sum types. We also discuss various interpretations of holes, and in so doing reveal connections with gradual typing and contextual modal type theory, the Curry-Howard interpretation of contextual modal logic. Finally, we discuss how Hazelnut's semantics lends itself to implementation as an event-based functional reactive program. Our simple reference implementation is written using js\_of\_ocaml.},
booktitle = {Proceedings of the 44th {ACM} {SIGPLAN} {Symposium} on {Principles} of {Programming} {Languages}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Omar, Cyrus and Voysey, Ian and Hilton, Michael and Aldrich, Jonathan and Hammer, Matthew A.},
year = {2017},
note = {event-place: Paris, France},
doi = {10.1145/2513228.2513271},
abstract = {In this paper, we consider how energy consumption can be reduced in the Priority-based Functional Reactive Programming (P-FRP) execution model through the implementation of Dynamic Voltage and Frequency Scaling (DVFS), a technique for modifying circuit delays and altering the operating frequency of the CPU. Use of DVFS can have an impact on task execution time, which adversely affects the temporal guarantees required from the real-time scheduler. Most of the existing studies provide solutions which are suitable for the classical model of preemptive task scheduling. Tasks which are schedulable in the preemptive model cannot be guaranteed to be schedulable in P-FRP, since the abort-based preemptive approach often creates additional costs in terms of response times.},
booktitle = {Proceedings of the 2013 {Research} in {Adaptive} and {Convergent} {Systems}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Belwal, Chaitanya and Cheng, Albert M. K. and Ras, J. and Wen, Yuanfeng},
year = {2013},
note = {event-place: Montreal, Quebec, Canada},
@techreport{transforma_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},
title = {Derivable {Type} {Classes}},
volume = {41},
issn = {1571-0661},
- url = {https://www.sciencedirect.com/science/article/pii/S1571066105805420},
doi = {https://doi.org/10.1016/S1571-0661(05)80542-0},
abstract = {Generic programming allows you to write a function once, and use it many times at different types. A lot of good foundational work on generic programming has been done. The goal of this paper is to propose a practical way of supporting generic programming within the Haskell language, without radically changing the language or its type system. The key idea is to present generic programming as a richer language in which to write default method definitions in a class declaration. On the way, we came across a separate issue, concerning type-class overloading where higher kinds are involved. We propose a simple type-class system extension to allow the programmer to write richer contexts than is currently possible.},
number = {1},
doi = {10.1145/3412932.3412936},
abstract = {Small Microcontroller Units (MCUs) drive the omnipresent Internet of Things (IoT). These devices are small, cheap, and energy efficient. However, they are not very powerful and lack an Operating System. Hence it is difficult to apply high level abstractions and write software that stays close to the design.Task Oriented Programming (TOP) is a paradigm for creating multi-user collaborative systems. A program consists of tasks—descriptions of what needs to be done. The tasks represent the actual work and a task value is observable during execution. Furthermore, tasks can be combined and transformed using combinators.mTask is an embedded Domain Specific Language (eDSL) to program MCUs following the TOP paradigm. Previous work has described the mTask language, a static C code generator, and how to integrate mTask with TOP servers. This paper shows that for dynamic IOT applications, tasks must be sent at runtime to the devices for interpretation. It describes in detail how to compile specialized IOT TOP tasks to bytecode and how to interpret them on devices with very little memory. These additions allow the creation of complete, dynamic IOT applications arising from a single source using a mix of iTasks and mTask tasks. Details such as serialization and communication are captured in simple abstractions.},
booktitle = {Proceedings of the 31st {Symposium} on {Implementation} and {Application} of {Functional} {Languages}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Lubbers, Mart and Koopman, Pieter and Plasmeijer, Rinus},
editor = {Stutterheim, Jurriën and Chin, Wei Ngan},
year = {2019},
doi = {10.1145/3410992.3411002},
abstract = {Internet of Things (IoT) software stacks are notoriously complex, conventionally comprising multiple tiers/components and requiring that the developer not only uses multiple programming languages, but also correctly interoperate the components. A novel alternative is to use a single tierless language with a compiler that generates the code for each component, and for their correct interoperation.We report the first ever systematic comparison of tiered and tierless IoT software architectures. The comparison is based on two implementations of a non-trivial smart campus application. PRSS has a conventional tiered Python-based architecture, and Clean Wemos Super Sensors (CWSS) has a novel tierless architecture based on Clean and the iTask and mTask embedded DSLs. An operational comparison of CWSS and PRSS demonstrates that they have equivalent functionality, and that both meet the University of Glasgow (UoG) smart campus requirements.Crucially, the tierless CWSS stack requires 70\% less code than the tiered PRSS stack. We analyse the impact of the following three main factors. (1) Tierless developers need to manage less interoperation: CWSS uses two DSLs in a single paradigm where PRSS uses five languages and three paradigms. (2) Tierless developers benefit from automatically generated, and hence correct, communication. (3) Tierless developers can exploit the powerful high-level abstractions such as Task Oriented Programming (TOP) in CWSS. A far smaller and single paradigm codebase improves software quality, dramatically reduces development time, and improves the maintainability of tierless stacks.},
booktitle = {Proceedings of the 10th {International} {Conference} on the {Internet} of {Things}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Lubbers, Mart and Koopman, Pieter and Ramsingh, Adrian and Singer, Jeremy and Trinder, Phil},
year = {2020},
note = {event-place: Malmö, Sweden},
series = {{IFL} '22},
title = {First-{Class} {Data} {Types} in {Shallow} {Embedded} {Domain}-{Specific} {Languages} using {Metaprogramming}},
booktitle = {Proceedings of the 34st {Symposium} on {Implementation} and {Application} of {Functional} {Languages}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Lubbers, Mart and Koopman, Pieter and Plasmeijer, Rinus},
year = {2022},
note = {event-place: Kopenhagen, Denmark. in-press},
series = {{IFL} '22},
title = {Strongly-{Typed} {Multi}-{View} {Stack}-{Based} {Computations}},
booktitle = {Proceedings of the 34st {Symposium} on {Implementation} and {Application} of {Functional} {Languages}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Koopman, Pieter and Lubbers, Mart},
year = {2022},
note = {event-place: Kopenhagen, Denmark. under-review},
Programming Languages in Open Source Projects},
year = {2015},
isbn = {9781450333504},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
doi = {10.1145/2745802.2745805},
abstract = {Background: Anecdotal evidence suggests that software
title = {On Challenges in Engineering IoT Software Systems},
year = {2018},
isbn = {9781450365031},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
doi = {10.1145/3266237.3266263},
abstract = {Contemporary software systems, such as the Internet of
behind the Curtain of Lines-of-Code Metrics},
year = {2020},
isbn = {9781450381789},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
doi = {10.1145/3426428.3426921},
abstract = {Lines-of-code metrics (loc) are commonly reported in
title = {Towards Haskell in the Cloud},
year = {2011},
isbn = {9781450308601},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
doi = {10.1145/2034675.2034690},
abstract = {We present Cloud Haskell, a domain-specific language for
title = {A New Approach to Generic Functional Programming},
year = {2000},
isbn = {1581131259},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
doi = {10.1145/325694.325709},
abstract = {This paper describes a new approach to generic functional
Lenses},
year = {2014},
isbn = {9781450332842},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
doi = {10.1145/2746325.2746333},
abstract = {Most complex applications inevitably need to maintain
title = {Comparing Libraries for Generic Programming in Haskell},
year = {2008},
isbn = {9781605580647},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
doi = {10.1145/1411286.1411301},
abstract = {Datatype-generic programming is defining functions that
Language Interfaces},
year = {2010},
issue_date = {June 2010},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
volume = {45},
number = {6},
title = {Checking Type Safety of Foreign Function Calls},
year = {2005},
issue_date = {June 2005},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
volume = {40},
number = {6},
Web Applications},
year = {2014},
issue_date = {December 2014},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
volume = {49},
number = {12},
via low-energy Bluetooth on Zephyr OS.},
booktitle = {Proceedings of the 13th {ACM} {SIGPLAN} {International}
{Symposium} on {Haskell}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Valliappan, Nachiappan and Krook, Robert and Russo,
Alejandro and Claessen, Koen},
year = {2020},
booktitle = {Proceedings of the 22nd {International} {Symposium} on
{Principles} and {Practice} of {Declarative}
{Programming}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Sarkar, Abhiroop and Sheeran, Mary},
year = {2020},
note = {event-place: Bologna, Italy},
Runtime},
year = {2018},
isbn = {9781450360661},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
doi = {10.1145/3281366.3281370},
abstract = {Reactive programming over a network is a challenging task
{Language} for {Small}-{Scale} {Embedded} {Systems}},
isbn = {978-981-323-406-2 978-981-323-407-9},
shorttitle = {{CFRP}},
- url = {http://www.worldscientific.com/doi/abs/10.1142/9789813234079_0001},
doi = {10.1142/9789813234079_0001},
language = {en},
urldate = {2022-03-02},
booktitle = {Proceedings of the 8th {ACM} {SIGPLAN} {International}
{Workshop} on {Programming} {Based} on {Actors}, {Agents},
and {Decentralized} {Control}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Shibanai, Kazuhiro and Watanabe, Takuo},
year = {2018},
note = {event-place: Boston, MA, USA},
traditional dataflow languages.},
booktitle = {Proceedings of the 2002 {ACM} {SIGPLAN} {Workshop} on
{Haskell}},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
author = {Nilsson, Henrik and Courtney, Antony and Peterson, John},
year = {2002},
note = {event-place: Pittsburgh, Pennsylvania},
Languages},
year = {2014},
isbn = {9781450332101},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
doi = {10.1145/2661136.2661146},
abstract = {Tierless programming languages enable developing the
title = {arduino-copilot: {Arduino} programming in haskell using
the {Copilot} stream {DSL}},
shorttitle = {arduino-copilot},
- url = {//hackage.haskell.org/package/arduino-copilot},
+ url = {https://hackage.haskell.org/package/arduino-copilot},
urldate = {2020-02-14},
journal = {Hackage},
author = {Hess, Joey},
}
@Book{ strack2015getting,
- title = {Getting Started with Meteor. js JavaScript Framework},
+ title = {Getting Started with Meteor.js JavaScript Framework},
author = {Strack, Isaac},
year = {2015},
publisher = {Packt Publishing Ltd}
title = {Measurement and {Analysis} of {Hajime}, a {Peer}-to-peer
{IoT} {Botnet}},
isbn = {1-891562-55-X},
- url = {https://par.nsf.gov/biblio/10096257},
doi = {10.14722/ndss.2019.23488},
booktitle = {Network and {Distributed} {Systems} {Security} ({NDSS})
{Symposium} 2019},
address = {Nijmegen},
type = {Bachelor's {Thesis}},
title = {Security analysis of the {iTasks} framework},
- url = {http://www.ru.nl/publish/pages/769526/arjan_oortgiese.pdf},
language = {English},
urldate = {2017-04-08},
school = {Radboud University},
Programming},
year = {2019},
isbn = {9781450372497},
- publisher = {Association for Computing Machinery},
+ publisher = {ACM},
address = {New York, NY, USA},
doi = {10.1145/3354166.3354182},
booktitle = {Proceedings of the 21st International Symposium on
\input{subfilepreamble}
-\setcounter{chapter}{9}
+\setcounter{chapter}{10}
\begin{document}
\input{subfileprefix}
\input{subfilepreamble}
-\setcounter{chapter}{0}
+\setcounter{chapter}{1}
\begin{document}
\input{subfileprefix}
\input{subfilepreamble}
-\setcounter{chapter}{1}
+\setcounter{chapter}{2}
\begin{document}
\input{subfileprefix}
\documentclass[../thesis.tex]{subfiles}
\input{subfilepreamble}
-\setcounter{chapter}{-1}
+\setcounter{chapter}{0}
\begin{document}
\input{subfileprefix}
As program memory is mostly flash-based and only lasts a couple of thousands of writes before it wears out, it is not suitable for repeated reconfiguring and reprogramming.
These problems can be mitigated by dynamically sending code to be interpreted to the microcontroller.
-With interpretation, a specialized interpreter is flashed in the program memory once it receives the program code to execute at run time.
+With interpretation, a specialised 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.
This dissertation describes a \gls{DSL} that includes the high-level programming concepts of \gls{TOP}, while it can be executed on edge devices with very limited hardware requirements.
\usepackage[square]{natbib} % Cite bib entry completely
\setlength{\bibsep}{0.0pt}
-%\def\bibfont{\small}
+\def\bibfont{\footnotesize}
%\setcitestyle{numbers}
%\bibliographystyle{alpha}
\bibliographystyle{abbrvnat}
-%\apptocmd{\thebibliography}{\raggedright}{}{}
+\usepackage{ragged2e}
+\apptocmd{\thebibliography}{\RaggedRight}{}{}
\makeatletter
\let\saved@bibitem\@bibitem%
\newabbreviation[prefixfirst={a\ },prefix={an\ }]{FRP}{FRP}{functional reactive programming}
\newabbreviation[prefixfirst={a\ },prefix={an\ }]{FPGA}{FPGA}{field-programmable gate array}
\newabbreviation{GADT}{GADT}{generalised \glsxtrshort{ADT}}
-\newabbreviation{GHC}{GHC}{Glasgow \gls{HASKELL} Compiler}
+\newabbreviation{GHC}{GHC}{Glasgow \gls{HASKELL} compiler}
\newabbreviation{GPIO}{GPIO}{general-purpose \glsxtrlong{IO}}
\newabbreviation{GPL}{GPL}{general-purpose language}
\newabbreviation{GRS}{GRS}{graph rewriting system}
\newcommand{\cinline}[1]{\lstinline[language=c,postbreak=]|#1|}
\newcommand{\arduinoinline}[1]{\lstinline[language={[Arduino]C++},postbreak=]|#1|}
\newcommand{\pythoninline}[1]{\lstinline[language=Python,postbreak=]|#1|}
-\newcommand{\cleaninline}[1]{\lstinline[language=Clean,postbreak=]|#1|}
+\newcommand{\cleaninline}[2][]{\lstinline[language=Clean,postbreak=,#1]|#2|}
\newcommand{\cleaninputlisting}[2][]{\renewcommand*{\lstlistingname}{Listing (\gls{CLEAN})}\lstinputlisting[escapeinside={/*}{*/},language=Clean,#1]{\subfix{#2}}}
\newcommand{\haskellinline}[1]{\lstinline[language={[Regular]Haskell},postbreak=]|#1|}
\newcommand{\haskellinputlisting}[2][]{\renewcommand*{\lstlistingname}{Listing (\gls{HASKELL})}\lstinputlisting[language={[Regular]Haskell},#1]{\subfix{#2}}}
\my@chapter}
\makeatother
+% Mark source code in the margin par
+\newcommand{\srcmark}[1]{\marginpar[\footnotesize\emph{#1}]{\footnotesize\emph{#1}}}
+
\lstnewenvironment{lstPython}[1][]
{%
\lstset{language=Python, #1}
exit
fi
sed -i \
- -e '/url = {https\?:\/\/\(doi.org\|link\.springer\|ieeexplore\|dl\.acm\|services\.igi-global\|arxiv\.org\)/d'\
+ -e '/url = {https\?:\/\/\(doi.org\|link\.springer\|ieeexplore\|dl\.acm\|services\.igi-global\|arxiv\.org\|www.sciencedirect.com\)/d'\
+ -e 's/Association for Computing Machinery,/ACM,/g'\
-e 's/{Transforma Insights}/{&}/g'\
-e 's/{GHC Team}/{&}/g'\
-e 's/λ/$\\lambda$/g'\
% The actual document
\mainmatter%
\mainmatterfancy%
-\setcounter{chapter}{-1}
+%\setcounter{chapter}{-1}
\glsresetall{} % Reset glossary and thus the acronyms
% Introduction
\subfile{dsl/class} % Deep embedding with class
\subfile{dsl/first} % First-class data types
-\part[Orchestrating the Internet of Things using Task-O\-rien\-ted Programming]{\\[2ex]\smaller{}Orchestrating the Internet of Things using Task-O\-rien\-ted Programming}%
-\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/green} % Green computing
-\subfile{top/finale} % Conclusion
+% Part II
+\subfile{top/top}
\part[Tiered versus Tierless Programming]{\\[2ex]\smaller{}Tiered versus Tierless Programming}%
\label{prt:tvt}
\input{subfilepreamble}
-\setcounter{chapter}{2}
+\setcounter{chapter}{3}
\begin{document}
\input{subfileprefix}
\begin{itemize}
\item introducing edge device programming;
\item showing how to create the \emph{Hello World!} application for microcontrollers using \gls{ARDUINO} and \gls{MTASK};
- \item extending the idea to cooperative multitasking, uncovering problems using \gls{ARDUINO};
- \item demonstrating that upgrading to a multitasking variant is straightforward using \gls{MTASK};
- \item elaborating on integrating an edge device program with a server;
+ \item extending the idea to cooperative multitasking, uncovering problems using \gls{ARDUINO} that do not exist in \gls{MTASK};
\item and providing a reading guide for the remainder of the monograph.
\end{itemize}
\end{chapterabstract}
The edge layer of \gls{IOT} systems predominantly consists of microcontrollers.
-Microcontrollers are tiny computers designed specifically for embedded applications that differ much from regular computers.
-They are much smaller; only have a fraction of the memory and processor speed; and run on different architectures.
-However, they have much more energy-efficient sleep modes, and support connecting and interfacing with peripherals such as sensors and actuators.
+Microcontrollers are tiny computers designed specifically for embedded applications.
+They differ significantly from regular computers in many aspects.
+For example, they are much smaller; only have a fraction of the memory and processor speed; and run on different architectures.
+Furthermore, they have much more energy-efficient sleep modes, and support connecting and interfacing with peripherals such as sensors and actuators.
To illustrate the difference in characteristics, \cref{tbl:mcu_laptop} compares the hardware properties of a typical laptop with two popular microcontrollers.
Usually, programming microcontrollers requires an elaborate multi-step toolchain of compilation, linkage, binary image creation, and burning this image onto the flash memory of the microcontroller in order to run a program.
The software is usually a cyclic executive instead of tasks that run in an \gls{OS}.
\end{tabular}
\end{table}
-All models of microcontrollers require their own vendor-provided drivers, hardware abstraction layer, compilers and \glspl{RTS}.
-To structure this jungle of tools, platforms exist that provide abstraction layers over the low-level toolchains.
-An example of this is \gls{ARDUINO}\footnote{\refurl{https://www.arduino.cc}{\formatdate{19}{12}{2022}}}.
-It is specifically designed for education and prototyping and hence used here to illustrate traditional microcontroller programming.
-The popular \gls{ARDUINO} \ccpp{} dialect and accompanying libraries provide an abstraction layer for common microcontroller behaviour allowing the programmer to program multiple types of microcontrollers using a single language.
+All microcontroller models require their own vendor-provided drivers, hardware abstraction layer, compilers and \glspl{RTS}.
+To structure this jungle of tools, platforms exist that provide an abstraction layer over the low-level toolchains.
+An example of this is the \gls{ARDUINO} environment\footnote{\refurl{https://www.arduino.cc}{\formatdate{19}{12}{2022}}}.
Originally it was designed for the in-house developed open-source hardware with the same name but the setup allows porting to many architectures by vendor-provided \emph{cores}.
-It provides an \gls{IDE} and toolchain automation to easily run code with a single press of a button.
+This set of tools is specifically designed for education and prototyping and hence used here to illustrate traditional microcontroller programming.
+It consists of an \gls{IDE} containing toolchain automation, a dialect of \ccpp{}, and libraries providing an abstraction layer for microcontroller behaviour.
+With \gls{ARDUINO}, the programmer can program multiple types of microcontrollers using a single language.
+Using the \gls{IDE} and toolchain automation, code can be executed easily on many types of microcontrollers with a single press of a button.
\section{TOP for the IoT}
\Gls{TOP} is a programming paradigm that allows multi-tier interactive systems to be generated from a single declarative source (see \cref{sec:back_top}).
An example of a \gls{TOP} system is \gls{ITASK}, a general-purpose \gls{TOP} language for programming interactive distributed web applications.
-Such web applications often form the core of the top two layers of an \gls{IOT} application.
-\Gls{IOT} edge devices are typically programmed with similar workflow-like programs for which \gls{TOP} is very suitable.
+Such web applications often form the core of the topmost two layers of \gls{IOT} applications: the presentation and application layer.
+Furthermore, \gls{IOT} edge devices are typically programmed with similar workflow-like programs for which \gls{TOP} is very suitable.
Directly incorporating the perception layer, and thus edge devices, in \gls{ITASK} however is not straightforward.
The \gls{ITASK} system is targetting relatively fast and hence energy-hungry systems with large amounts of \gls{RAM} and a speedy connection.
Edge devices in \gls{IOT} systems are typically slow but energy efficient and do not have the memory to run the naturally heap-heavy feature-packed functional programs that \gls{ITASK} programs are.
The \gls{MTASK} system bridges this gap by providing a domain-specific \gls{TOP} language for \gls{IOT} edge devices.
-Domain-specific knowledge is embedded in the language and execution platform; and unnecessary features for edge devices are removed to drastically lowere the hardware requirements.
-Programs in \gls{MTASK} are written in the same abstraction level as \gls{ITASK} in the \gls{MTASK} \gls{DSL}.
-When executed, they are fully integrated in the \gls{ITASK} host, allowing for programming entire \gls{IOT} systems from a single abstraction level, source code, and programming paradigm.
+Domain-specific knowledge is embedded in the language and execution platform and unnecessary features for edge devices are removed to drastically lower the hardware requirements.
+Programs in \gls{MTASK} are written in the \gls{MTASK} \gls{DSL}, a \gls{TOP} language that offers a similar abstraction level as \gls{ITASK}.
+Tasks in \gls{MTASK} operate as if they are \gls{ITASK} tasks, their task value is observable by other tasks and they can share data using \gls{ITASK} \glspl{SDS}.
+This allows for programming entire \gls{IOT} systems from a single abstraction level, source code, and programming paradigm.
\section{Hello world!}
Traditionally, the first program that one writes when trying a new language is the so-called \emph{Hello World!} program.
Nevertheless, almost always there is a built-in 1 pixel screen with a \qty{1}{\bit} color depth, namely the on-board \gls{LED}.
The \emph{Hello World!} equivalent on microcontrollers blinks this \gls{LED}.
-Using \gls{ARDUINO}'s \ccpp{} dialect to create the blink program, results in the code seen in \cref{lst:arduinoBlink}.
+Creating a blink program using \ccpp{} and the \gls{ARDUINO} libraries result in the code seen in \cref{lst:arduinoBlink}.
\Gls{ARDUINO} programs are implemented as cyclic executives and hence, each program defines a \arduinoinline{setup} and a \arduinoinline{loop} function.
The \arduinoinline{setup} function is executed only once on boot, the \arduinoinline{loop} function is continuously called afterwards and contains the event loop.
+In between the executions of the \arduinoinline{loop} function, system and maintenance code is executed.
In the blink example, the \arduinoinline{setup} function only contains code for setting the \gls{GPIO} pin to the correct mode.
The \arduinoinline{loop} function alternates the state of the pin representing the \gls{LED} between \arduinoinline{HIGH} and \arduinoinline{LOW}, turning the \gls{LED} off and on respectively.
In between, it waits \qty{500}{\ms} so that the blinking is actually visible for the human eye.
}\end{lstArduino}
\subsection{Blinking the LED in mTask}
-Naively translating the traditional blink program to \gls{MTASK} can be done by simply substituting some syntax as seen in \cref{lst:blinkImp}.
+Naively translating the traditional blink program to \gls{MTASK} can be done by simply substituting syntax as seen in \cref{lst:blinkImp}.
E.g.\ \arduinoinline{digitalWrite} becomes \cleaninline{writeD}, literals are prefixed with \cleaninline{lit}, and \arduinoinline{pinMode} becomes \arduinoinline{declarePin}.
In contrast to the imperative \gls{CPP} dialect, \gls{MTASK} is a \gls{TOP} language and therefore there is no such thing as a loop, only task combinators to combine tasks.
The task is not the single cyclic executive and therefore consists of just a main expression.
The task resulting from the main expression is continuously executed by the \gls{RTS}.
To simulate a loop, the \cleaninline{rpeat} task combinator is used as this task combinator executes the argument task and, when stable, reinstates it.
-The body of the \cleaninline{rpeat} task contanis a task that writes to the pins and waits in between.
+The body of the \cleaninline{rpeat} task contains a task that writes to the pins and waits in between.
The tasks are connected using the sequential \cleaninline{>>|.} combinator that for all current intents and purposes executes the tasks after each other.
\begin{lstClean}[caption={Blinking the \gls{LED} using the \cleaninline{rpeat} combinator.},label={lst:blinkImp}]
}
\end{lstClean}
-The \gls{MTASK} \gls{DSL} is hosted in a full fledged \gls{FP} language.
+The \gls{MTASK} \gls{DSL} is hosted in a full-fledged \gls{FP} language.
It is therefore also possible to define the blinking behaviour as a function.
\Cref{lst:blinkFun} shows this more natural translation.
-The \cleaninline{main} expression is just a call to the \cleaninline{blink} function parametrised with the state.
-The \cleaninline{blink} function first writes the current state to the \gls{LED}, waits for the specific time and calls itself recursively with the inverse of the state, resulting in the blinking behaviour.
+The \cleaninline{main} expression is a call to the \cleaninline{blink} function parametrised with the state.
+The \cleaninline{blink} function first writes the current state to the \gls{LED}, waits for the specific time, and calls itself recursively with the inverse of the state, resulting in the blinking behaviour.
Creating recursive functions like this is not possible in the \gls{ARDUINO} language because the program would run out of stack quickly and combining multiple tasks defined like this would be very difficult.
\begin{lstClean}[caption={Blinking the \gls{LED} using a function.},label={lst:blinkFun}]
\section{Multitasking}
Now say that we want to blink multiple blinking patterns on different \glspl{LED} concurrently.
For example, blink three \glspl{LED} connected to \gls{GPIO} pins $1,2$ and $3$ at intervals of \qtylist{500;300;800}{\ms}.
-Intuitively you would want to lift the blinking behaviour to a function in order to minimise duplicate code and increase modularity and call this function three times with different parameters as shown in \cref{lst:blinkthreadno}.
+Intuitively, you would want to lift the blinking behaviour to a function in order to minimise duplicate code, and increase modularity by calling this function three times with different parameters as shown in \cref{lst:blinkthreadno}.
\begin{lstArduino}[caption={Naive approach to multiple blinking patterns.},label={lst:blinkthreadno}]
void setup () { ... }
blink (D3, 800);
}\end{lstArduino}
-Unfortunately, this does not work because the \arduinoinline{delay} function blocks all further execution.
+Unfortunately, this does not work because the \arduinoinline{delay} function blocks all other execution.
The resulting program blinks the \glspl{LED} after each other instead of at the same time.
-To overcome this, it is necessary to slice up the blinking behaviour in very small fragments and interleave it manually \citep{feijs_multi-tasking_2013}.
+To overcome this, it is necessary to slice up the blinking behaviour in small fragments and interleave it manually \citep{feijs_multi-tasking_2013}.
\Cref{lst:blinkthread} shows how three different blinking patterns could be implemented in \gls{ARDUINO} using the slicing method.
If we want the blink function to be a separate parametrisable function we need to explicitly provide all references to the required global state.
Furthermore, the \arduinoinline{delay} function can not be used and polling \arduinoinline{millis} is required.
-The \arduinoinline{millis} function returns the number of \unit{\ms} that have passed since the boot of the microcontroller.
-If the delay is long enough, it may also be possible to put the processor in sleep mode, reducing the power consumption drastically.
-Hence, using \arduinoinline{millis} potentially affects power consumption since the processor is busy looping all the time.
+The \arduinoinline{millis} function returns the number of milliseconds that have passed since the boot of the microcontroller.
+If the delay passed to the \arduinoinline{delay} function is long enough, the firmware may decide to put the processor in sleep mode, reducing the power consumption drastically.
+When polling \arduinoinline{millis} is used, this therefore potentially affects power consumption since the processor is busy looping all the time, not knowing when to go to sleep.
Manually combining tasks into a single modular program is very error prone, requires a lot of pointer juggling, and generally results into spaghetti code.
Furthermore, it is very difficult to represent dependencies between threads.
Often state machines have to be explicitly programmed and merged by hand to achieve this.
\subsection{Multitasking in mTask}
In contrast to the \arduinoinline{delay} function in \gls{ARDUINO}, \gls{MTASK}'s \cleaninline{delay} \emph{task} does not block the execution.
-It has no observable value until the target waiting time has passed, and thence is \emph{stable}.
-To make code reuse possible and make the implementation more intuitive, the blinking behaviour is lifted to a recursive function as well instead of using the imperatively looking \cleaninline{rpeat} task combinator.
-There is no global state, the function is parametrized with the current status, the pin to blink and the waiting time.
-With a parallel combinator, tasks are executed in an interleaved fashion.
+It has no observable value until the target waiting time has passed, and is thence \emph{stable}.
+As there is no global state, the function is parametrised with the current status, the pin to blink and the waiting time.
+With a parallel combinator, tasks are executed at the same time.
Therefore, blinking three different blinking patterns is as simple as combining the three calls to the \cleaninline{blink} function with their arguments as seen in \cref{lst:blinkthreadmtask}.
% VimTeX: SynIgnore on
The edge layer of \gls{IOT} systems is powered by microcontrollers.
Microcontrollers have significantly different characteristics to regular computers.
Programming them happens through compiled firmwares using low-level imperative programming languages.
-Due to the lack of an \gls{OS}, writing applications that perform multiple tasks at the same time is error prone, becomes complex, requires a lot of boilerplate, and needs manual scheduling code.
+Due to the lack of an \gls{OS}, writing applications that perform multiple tasks at the same time is error prone, becomes complex, and requires a lot of boilerplate such as manual scheduling code.
With the \gls{MTASK} system, a \gls{TOP} programming language for \gls{IOT} edge devices, this limitation can be overcome.
Since much domain-specific knowledge is built into the language and \gls{RTS}, the hardware requirements can be kept relatively low while maintaining a high abstraction level.
Furthermore, the programs are automatically integrated with \gls{ITASK}, a \gls{TOP} system for creating interactive distributed web applications, allowing for data sharing, task coordination, and dynamic construction of tasks.
-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}.
+The following chapters of this monograph thoroughly introduce all aspects of the \gls{MTASK} system.
+First the language setup and interface are shown in \cref{chp:mtask_dsl}.
\Cref{chp:integration_with_itask} shows the integration of \gls{MTASK} and \gls{ITASK}.
-Then, \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:green_computing_mtask} explains all 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}.
+Finally, \cref{chp:finale} concludes, shows related work, and provides a short history of \gls{MTASK}.
\input{subfilepostamble}
\end{document}
\input{subfilepreamble}
-\setcounter{chapter}{7}
+\setcounter{chapter}{8}
\begin{document}
\input{subfileprefix}
\input{subfilepreamble}
-\setcounter{chapter}{6}
+\setcounter{chapter}{7}
\begin{document}
\input{subfileprefix}
Furthermore, many \gls{IOT} devices operate on batteries and higher energy consumption increases the amount of e-waste as \gls{IOT} edge devices are often hard to reach and consequently hard to replace \citep{nizetic_internet_2020}.
It is therefore crucial to lower their energy consumption.
-To reduce the power consumption of an \gls{IOT} edge device, the specialized low-power sleep modes of the microprocessors can be leveraged.
+To reduce the power consumption of an \gls{IOT} edge device, the specialised low-power sleep modes of the microprocessors can be leveraged.
Different sleep mode achieve different power reductions because of their run time characteristics.
These specifics range from disabling or suspending the \gls{WIFI} radio; stop powering (parts) of the \gls{RAM}; disabling peripherals; or even turning off the processor completely, requiring an external signal to wake up again.
Determining exactly when, and for how long it is safe to sleep is expensive in the general case.
The interrupt handler is set up in such a way that the rewrite rate is changed to $\rewriterate{0}{0}$ once the interrupt triggers.
As a consequence, the task is executed on the next execution cycle.
-The \cleaninline{pirSwitch} function in \cref{lst:pirSwitch} creates, given an interval in \unit{\ms}, a task that reacts to motion detection by a \gls{PIR} sensor (connected to \gls{GPIO} pin 0) by lighting the \gls{LED} connected to \gls{GPIO} pin 13 for the given interval.
+The \cleaninline{pirSwitch} function in \cref{lst:pirSwitch} creates, given an interval in milliseconds, a task that reacts to motion detection by a \gls{PIR} sensor (connected to \gls{GPIO} pin 0) by lighting the \gls{LED} connected to \gls{GPIO} pin 13 for the given interval.
The system turns on the \gls{LED} again when there is still motion detected after this interval.
By changing the interrupt mode in this program text from \cleaninline{high} to \cleaninline{rising} the system lights the \gls{LED} only one interval when it detects motion, no matter how long this signal is present at the \gls{PIR} pin.
\input{subfilepreamble}
-\setcounter{chapter}{4}
+\setcounter{chapter}{6}
\begin{document}
\input{subfileprefix}
When a new task is received, the main expression is evaluated to produce a task tree.
A task tree is a tree structure in which each node represents a task combinator and the leaves are basic tasks.
-If a task is not initialized yet, i.e.\ the pointer to the current task tree is still null, the byte code of the main function is interpreted.
+If a task is not initialised yet, i.e.\ the pointer to the current task tree is still null, the byte code of the main function is interpreted.
The main expression always produces a task tree.
Execution of a task consists of continuously rewriting the task until its value is stable.
+%chktex-file 17
\documentclass[../thesis.tex]{subfiles}
\input{subfilepreamble}
-\setcounter{chapter}{5}
+\setcounter{chapter}{6}
\begin{document}
\input{subfileprefix}
Furthermore, the \gls{MTASK} tasks interact with \gls{ITASK} \glspl{SDS} using the \cleaninline{lowerSds} construct.
All of this together allows programming all layers of an \gls{IOT} system from a single source and in a single paradigm.
All details regarding interoperation are automatically taken care of.
-The following section contains an elaborate example using all integration functions that has deliberately been placed after the conclusion so that the code listing and description are on facing pages.
+The following section contains an elaborate example using all integration functions that has deliberately been placed after the conclusion.
+
+\newpage
+\vspace*{\fill}
+\hfill
+\begin{center}
+ \cleaninline[basewidth=.2em,columns=flexible,basicstyle=\tt\footnotesize]{let p = [['This page would be intentionally blank if I were not telling you that ']:p] in p} % chktex 10
+\end{center}
+\vspace{\fill}
+\newpage
-\begin{figure}[p]
- \begin{fullpage}
-% \begin{leftfullpage}
- \vspace{\headsep}
\section{Home automation}
This section presents an interactive home automation program (\cref{lst:example_home_automation}) to illustrate the integration of the \gls{MTASK} language and the \gls{ITASK} system.
-It consists of a web interface for the user to control which tasks are executed on either one of two connected devices: an \gls{ARDUINO} UNO, connected via a serial port; and an ESP8266 based prototyping board called NodeMCU, connected via \gls{TCP} over \gls{WIFI}.
-
+It consists of a web interface for the user to control which tasks are executed on either one of two connected devices: an \gls{ARDUINO} UNO, connected via a serial port; and an ESP8266 based prototyping board called NodeMCU, connected via \gls{TCP}\slash{}\gls{WIFI}.
\Crefrange{lst:example:spec1}{lst:example:spec2} show the specification for the devices.
The UNO is connected via serial using the unix filepath \path{/dev/ttyACM0} and the default serial port settings.
The NodeMCU is connected via \gls{WIFI} and hence the \cleaninline{TCPSettings} record is used.
-Both types have \cleaninline{channelSync} instances.
+%Both types have \cleaninline{channelSync} instances.
The code consists of an \gls{ITASK} part and several \gls{MTASK} parts.
\Crefrange{lst:example:task1}{lst:example:task2} contains the \gls{ITASK} task that coordinates the \gls{IOT} application.
-First the devices are connected (\crefrange{lst:example:conn1}{lst:example:conn2}) followed by launching a \cleaninline{parallel} task, visualized as a tabbed window, and a shutdown button to terminate the program (\crefrange{lst:example:par1}{lst:example:par2}).
+First the devices are connected (\crefrange{lst:example:conn1}{lst:example:conn2}) followed by launching a \cleaninline{parallel} task, visualised as a tabbed window, and a shutdown button to terminate the program (\crefrange{lst:example:par1}{lst:example:par2}).
This parallel task is the controller of the tasks that run on the edge devices.
It contains one task that allows adding new tasks (using \cleaninline{appendTask}) and all other tasks in the process list will be \gls{MTASK} tasks once they are added by the user.
The controller task, \cleaninline{chooseTask} as shown in \crefrange{lst:example:ct1}{lst:example:ct2}, allows the user to pick a task, and sending it to the specified device.
Using \cleaninline{lowerSds}, the status of the light switch is synchronised with the user.
Finally, a task that calculates the factorial of a user-provided number is shown in the list.
- \vspace{4ex}
- \begin{center}
- \begin{subfigure}[b]{.3\linewidth}
- \includegraphics[width=\linewidth]{home_auto1}
- \caption{Select task.}%
- \label{fig:example_screenshots1}
- \end{subfigure}
- \begin{subfigure}[b]{.3\linewidth}
- \includegraphics[width=\linewidth]{home_auto2}
- \caption{Select device.}%
- \label{fig:example_screenshots2}
- \end{subfigure}
- \begin{subfigure}[b]{.3\linewidth}
- \includegraphics[width=\linewidth]{home_auto3}
- \caption{View result.}%
- \label{fig:example_screenshots3}
- \end{subfigure}
- \caption{Screenshots of the home automation example program in action.}%
- \label{fig:example_screenshots}
- \end{center}
- %\end{leftfullpage}
- \end{fullpage}
+\begin{figure}[!ht]
+ \centering
+ \begin{subfigure}[b]{.3\linewidth}
+ \includegraphics[width=\linewidth]{home_auto1}
+ \caption{Select task.}%
+ \label{fig:example_screenshots1}
+ \end{subfigure}
+ \begin{subfigure}[b]{.3\linewidth}
+ \includegraphics[width=\linewidth]{home_auto2}
+ \caption{Select device.}%
+ \label{fig:example_screenshots2}
+ \end{subfigure}
+ \begin{subfigure}[b]{.3\linewidth}
+ \includegraphics[width=\linewidth]{home_auto3}
+ \caption{View result.}%
+ \label{fig:example_screenshots3}
+ \end{subfigure}
+ \caption{Screenshots of the home automation example program in action.}%
+ \label{fig:example_screenshots}
\end{figure}
\begin{figure}[p]
\input{subfilepreamble}
-\setcounter{chapter}{3}
+\setcounter{chapter}{4}
\begin{document}
\input{subfileprefix}
--- /dev/null
+\documentclass[../thesis.tex]{subfiles}
+
+\input{subfilepreamble}
+
+%\let\ifSubfilesClassLoadedOld\ifSubfilesClassLoaded%
+%\ifSubfilesClassLoadedOld{
+% \renewcommand{\ifSubfilesClassLoaded}[2]{#2}
+%}{}
+\begin{document}
+\input{subfileprefix}
+\part[Orchestrating the Internet of Things using Task-O\-rien\-ted Programming]{\\[2ex]\smaller{}Orchestrating the Internet of Things using Task-O\-rien\-ted Programming}%
+\label{prt:top}
+
+\subfile{4iot} % TOP for the IoT
+\subfile{lang} % mTask DSL
+\subfile{int} % Integration with iTask
+\subfile{imp} % Implementation
+\subfile{green} % Green computing
+\subfile{finale} % Conclusion
+
+%\let\ifSubfilesClassLoaded\ifSubfilesClassLoadedOld%
+\input{subfilepostamble}
+\end{document}
\input{subfilepreamble}
+\setcounter{chapter}{9}
+
\begin{document}
\input{subfileprefix}
\chapter{Could tierless languages reduce IoT development grief?}%
\begin{enumerate*}
\item Tierless languages benefit from reduced interoperation, requiring far fewer languages, paradigms and source code files e.g.\ \gls{CWS} uses two languages, one paradigm and three source code files where \gls{PWS} uses seven languages, two paradigms and 35 source code files
(\cref{table_t4t:multi,table_t4t:languages,table_t4t:paradigms}).
- \item Tierless languages benefit from automatically synthesized, and hence correct, communication between components that may be distributed.
+ \item Tierless languages benefit from automatically synthesised, and hence correct, communication between components that may be distributed.
\item Tierless languages benefit from high-level programming abstractions like compositional and higher-order task combinators (\cref{sec_t4t:ProgrammingComparison}).
\end{enumerate*}
Potato goes beyond other \gls{FRP} languages to provide a tierless \gls{FRP} \gls{IOT} language for resource rich sensor nodes \citep{troyer_building_2018}. It does so using the Erlang programming language and sophisticated virtual machine.
-TOP allows for more complex collaboration patterns than \gls{FRP} \citep{wang_maintaining_2018}, and in consequence is unable to provide the strong guarantees on memory usage available in a restricted variant of \gls{FRP} such as arrowized \gls{FRP} \citep{nilsson_functional_2002}.
+TOP allows for more complex collaboration patterns than \gls{FRP} \citep{wang_maintaining_2018}, and in consequence is unable to provide the strong guarantees on memory usage available in a restricted variant of \gls{FRP} such as arrowised \gls{FRP} \citep{nilsson_functional_2002}.
\subsubsection{Erlang\slash{}Elixir \IOT{} systems}
A number of production \gls{IOT} systems are engineered in Erlang or Elixir, and many are mostly tierless.
\Cref{lst_t4t:itaskTemp:measurementsSDS} defines a persistent \gls{SDS} to store a list of measurements, and for communication between tasks. The \gls{SDS} is analogous to the SQL DBMS in many tiered web applications.
TempHistory defines two tasks that interact with the \texttt{mea\-sure\-ments\-SDS}: \texttt{mea\-sure\-Task} adds measurements at each detected change in the temperature.
-It starts by defining a \cleaninline{dht} object as before, and then defines a recursive \cleaninline{task} function parameterized by the \cleaninline{old} temperature.
+It starts by defining a \cleaninline{dht} object as before, and then defines a recursive \cleaninline{task} function parameterised by the \cleaninline{old} temperature.
This function reads the temperature from the DHT sensor and uses the step combinator, \cleaninline{>>*}, to compose it with a list of actions.
The first of those actions that is applicable determines the continuation of this task. If no action is applicable, the task on the left-hand side is evaluated again.
The first action checks whether the new temperature is different from the \cleaninline{old} temperature (\cref{lst_t4t:itaskTemp:action1}). If so, it records the current time and adds the new measurements to the \cleaninline{measurementsSDS}.
The \cleaninline{latestTemp} is a \emph{lens} on the \cleaninline{tempSDS}.
A lens is a new \gls{SDS} that is automatically mapped to another \gls{SDS}.
Updating one of the \glspl{SDS} that are coupled in this way automatically updates the other.
-The function \cleaninline{mapReadWrite} is parameterized by the read and write functions, the option to handle asynchronous update conflicts (here \cleaninline{?None}) and the \gls{SDS} to be transformed (here \cleaninline{tempSDS}).
+The function \cleaninline{mapReadWrite} is parameterised by the read and write functions, the option to handle asynchronous update conflicts (here \cleaninline{?None}) and the \gls{SDS} to be transformed (here \cleaninline{tempSDS}).
The result of reading is the head of the list, if it exists.
The type for writing \cleaninline{latestTemp} is a tuple with a new \cleaninline{DateTime} and temperature as \cleaninline{Real}.
The \cleaninline{mainTask} is a simple \gls{ITASK} task that starts the \cleaninline{devTask} \gls{MTASK} task on the device identified by \cleaninline{deviceInfo} (\cref{lst_t4t:mtasktemp:withdevice}). At runtime the \gls{MTASK} slice is compiled to byte code, shipped to the indicated device, and launched. Thereafter, \cleaninline{mainTask} reads temperature values from the \cleaninline{latestTemp} \gls{SDS} that is shared with the \gls{MTASK} device, and displays them on a web page (\cref{fig_t4t:cwtsweb}). The \gls{SDS}---shared with the device using \cleaninline{lowerSds}---automatically communicates new temperature values from the microcontroller to the server.
-While this simple application makes limited use of the \gls{MTASK} \gls{EDSL}, it illustrates some powerful \gls{MTASK} program abstractions like basic tasks, task combinators, named recursive and parameterized tasks, and \glspl{SDS}.
+While this simple application makes limited use of the \gls{MTASK} \gls{EDSL}, it illustrates some powerful \gls{MTASK} program abstractions like basic tasks, task combinators, named recursive and parameterised tasks, and \glspl{SDS}.
Function composition (\cref{lst_t4t:mtasktemp:o}) and currying (\cref{lst_t4t:mtasktemp:setSds}) are inherited from the \gls{CLEAN} host language.
As \gls{MTASK} tasks are dynamically compiled, it is also possible to select and customise tasks as required at runtime.
For example, the interval used in the \cleaninline{rpeatevery} task (\cref{lst_t4t:mtasktemp:rpeatevery}) could be a parameter to the \cleaninline{devTask} function.
-\newcommand{\srcmark}[1]{\marginpar[\footnotesize\emph{#1}]{\footnotesize\emph{#1}}}
\begin{lstClean}[%
numbers=left,
caption={
%\subsubsection{Memory Consumption}%
\label{sec_t4t:MemPower}
-\paragraph{Memory} By design sensor nodes are devices with limited computational capacity, and memory is a key restriction. Even supersensors often have less than a \unit{\gibi\byte} of memory, and microcontrollers often have just tens of \unit{\kibi\byte{}s}.
+\paragraph{Memory} By design sensor nodes are devices with limited computational capacity, and memory is a key restriction. Even supersensors often have less than a \unit{\gibi\byte} of memory, and microcontrollers often have just tens of \unit{\kibi\byte}.
%In a tiered implementation the memory residency of the sensor node code can be minimised by carefully crafting it in a language that minimises memory residency. However, ...
As the tierless languages synthesize the code to be executed on the sensor nodes, we need to confirm that the generated code is sufficiently memory efficient.
We show that a bare metal execution environment allows \gls{MTASK} to have better control of peripherals, timing and energy consumption.
The memory available on a microcontroller restricts the programming abstractions available in \gls{MTASK} to a fixed set of combinators, no user defined or recursive data types, strict evaluation, and makes it harder to add new abstractions.
Even with these restrictions \gls{MTASK} provide a higher level of abstraction than most bare metal languages, and can readily express many \gls{IOT} applications including the \gls{CWS} \gls{UOG} smart campus application (\cref{sec_t4t:ComparingTierless}).
-Our empirical results are consistent with the benefits of tierless languages listed in Section 2.1 of \citep{weisenburger2020survey}.
+Our empirical results are consistent with the benefits of tierless languages listed in \citet[\citesection{2.1}]{weisenburger2020survey}.
\subsection{Reflections}
repositories / phd-thesis.git / commitdiff