\end{lstClean}
\subsection{\texorpdfstring{\gls{I2C}}{I\textsuperscript{2}C} buttons}
-The \gls{MTASK} language supports one type of \gls{I2C} buttons (the \gls{I2C} buttons from the WEMOS d1 mini \gls{OLED} shield).
+The \gls{MTASK} language supports one type of \gls{I2C} buttons (the \gls{I2C} buttons from the \gls{WEMOS} d1 mini \gls{OLED} shield).
The buttons from this shield provide more information than just the status (see \cleaninline{ButtonStatus}).
The complete interface containing the constructor and the measurement tasks is shown in \cref{lst:mtask_i2cbutton}.
\end{lstClean}
\subsection{\texorpdfstring{\gls{LED}}{LED} matrix}
-The \gls{MTASK} language supports one type of \gls{LED} matrix (the $8\times8$ \gls{LED} matrix shield for the WEMOS d1 mini).
+The \gls{MTASK} language supports one type of \gls{LED} matrix (the $8\times8$ \gls{LED} matrix shield for the \gls{WEMOS} d1 mini).
Instead of containing a \gls{TOP}-like interface, the \gls{ARDUINO} interface is directly translated to \gls{MTASK}.
As a result, every task immediately returns a stable value indicating the result.
The complete interface containing the constructor and the interaction tasks is shown in \cref{lst:mtask_ledmatrix}.
\chapter{Coda}%
\label{chp:conclusion}
+\section{Conclusion}
+
+\section{Future work}
\input{subfilepostamble}
\end{document}
\chapter{\texorpdfstring{\Acrshort{DSL}}{DSL} embedding techniques}%
\label{chp:dsl_embedding_techniques}%
An \gls{EDSL} is a language embedded in a host language created for a specific domain\todo{citation needed?}.
-Properties such as referential transparency, minimal syntax and \glspl{ADT} make \gls{FP} languages excellent candidates for hosting \glspl{EDSL}.
-Terms in an \glspl{EDSL} can have multiple interpretations---also called backends or views---i.e.\ preferably, a term in the \gls{DSL} is just an interface.
+Properties such as referential transparency, minimal syntax, powerful type systems and rich data types make \gls{FP} languages excellent candidates for hosting \glspl{EDSL}.
+
+There are two flavours of \gls{DSL} embedding: deep- and shallow embedding~\citep{boulton_experience_1992}.
+Shallow embedding---also called tagless embedding---models language constructs as functions in the host language.
+As a result, adding new language constructs---extra functions---is easy.
+However, the interpretation of the language is embedded in these functions, making it troublesome to add semantics since it requires updating all existing language constructs.
+
+In contrast to shallow embedding, deep embedding---also called tagged embedding---models terms in the language as data types.
+Interpretations are functions over these data types.
+
+Consequently, adding new semantics, i.e.\ novel functions, is straightforward.
+It can be stated that the language constructs are embedded in the functions that form a semantics.
+If one wants to add a language construct, all semantics functions must be revisited and revised to avoid ending up with partial functions.
+
+This juxtaposition has been known for many years~\citep{reynolds_user-defined_1978} and discussed by many others~\citep{krishnamurthi_synthesizing_1998} but most famously dubbed the \emph{expression problem} by Wadler~\citep{wadler_expression_1998}:
+
+\begin{quote}
+ The \emph{expression problem} is a new name for an old problem.
+ The goal is to define a data type by cases, where one can add new cases to the data type and new functions over the data type, without recompiling existing code, and while retaining static type safety (e.g., no casts).
+\end{quote}
+
+Terms in an \glspl{EDSL} can have multiple interpretations\footnote{Interpretations are also called backends or views}, i.e.\ a term in the \gls{DSL} is just an interface.
Commonly used intepretations are printing, compiling, simulating, optimising, verifying, proving the program\etc.
-There are two main flavours of embedding \glspl{DSL}, deep---also called tagged---embedding and shallow---also called tagless---embedding.
+There are two main flavours of embedding \glspl{DSL}.
+Deep embedding---also called shallow--- models terms in the language as data types, interpretations are functions over these terms.
+Shallow embedding---also called tagless---models terms in the language as functions, interpretations are embedded in these functions.
Most importantly, the two flavours differ on two axes: extensibility of language constructs and extensibility of interpretations.
\todo{elaborate}
\pagenumbering{arabic}
}{}
-\chapter[First-class data types in shallow \acrshortpl{EDSL} using metaprogramming]{First-class data types in shallow \acrlongpl{EDSL} using metaprogramming}%
+\chapter{First-class data types in shallow \acrlongpl{EDSL} using metaprogramming}%
\label{chp:first-class_datatypes}%
\begin{chapterabstract}
\Gls{FP} languages are excellent candidates for hosting \glspl{EDSL} because of their rich type systems, minimal syntax, and referential transparency.
For example, reifying a type name results in information about the type and the corresponding AST nodes of the type's definition.
This information can then be used to generate code according to the structure of data types.
Reification is done using the \haskellinline{reify :: Name -> Q Info} function.
-The \haskellinline{Info} type is an \gls{ADT} containing all the---known to the compiler---information about the matching type: constructors, instances, etc.
+The \haskellinline{Info} type is an \gls{ADT} containing all the---known to the compiler---information about the matching type: constructors, instances, \etc.
\section{Metaprogramming for generating \texorpdfstring{\acrshort{DSL}}{DSL} functions}
With the power of metaprogramming, we can generate the boilerplate code for our user-defined data types automatically at compile time.
-% Acronyms
-\newacronym{3COWS}{3COWS}{The three ``CO'' (Composability, Comprehensibility, Correctness) winter school}
-\newacronym{ADC}{ADC}{analog-to-digital converter}
-\newacronym{ADT}{ADT}{algebraic data type}
-\newacronym{API}{API}{application programming interface}
-\newacronym{ARDSL}{ARDSL}{\gls{ARDUINO} \acrshort{DSL}}
-\newacronym{BLE}{BLE}{Bluetooth low energy}
-\newacronym{CEFP}{CEFP}{central European summer school of \acrlong{FP}}
-\newacronym{CRS}{CRS}{\gls{CLEAN} Raspberry Pi system}
-\newacronym{CRTS}{CRTS}{\gls{CLEAN} Raspberry Pi temperature sensor}
-\newacronym{CWS}{CWS}{\gls{CLEAN} wemos system}
-\newacronym{CWTS}{CWTS}{\gls{CLEAN} wemos temperature sensor}
-\newacronym{DHT}{DHT}{digital humidity and temperature}
-\newacronym{DSL}{DSL}{domain-specific language}
-\newacronym{ECO2}{eCO\textsubscript{2}}{equivalent carbon dioxide}
-\newacronym{EDSL}{eDSL}{embedded \acrshort{DSL}}
-\newacronym{FP}{FP}{functional programming}
-\newacronym{FRP}{FRP}{functional reactive programming}
-\newacronym{GADT}{GADT}{generalised \acrshort{ADT}}
-\newacronym{GHC}{GHC}{Glasgow \gls{HASKELL} Compiler}
-\newacronym{GPIO}{GPIO}{general-purpose \acrlong{IO}}
-\newacronym{GPL}{GPL}{general-purpose language}
-\newacronym{GRS}{GRS}{graph rewriting system}
-\newacronym{GUI}{GUI}{graphical \acrlong{UI}}
-\newacronym{HOAS}{HOAS}{high-order abstract syntax}
-\newacronym{IOT}{IoT}{internet of things}
-\newacronym{IDE}{IDE}{integrated development environment}
-\newacronym{IO}{IO}{input/output}
-\newacronym{IR}{IL}{intermediate representation}
-\newacronym{LEAN}{LEAN}{language of East-Anglia and Nijmegen}
-\newacronym{LED}{LED}{light-emitting diode}
-\newacronym{MCU}{MCU}{microcontroller unit}
-\newacronym{OLED}{OLED}{organic \acrlong{LED}}
-\newacronym{OS}{OS}{operating system}
-\newacronym{OTA}{OTA}{over-the-air}
-\newacronym{PIR}{PIR}{passive infrared}
-\newacronym{PRS}{PRS}{\gls{PYTHON} Raspberry Pi system}
-\newacronym{PWS}{PWS}{\gls{MICROPYTHON} wemos system}
-\newacronym{PRTS}{PRTS}{\gls{PYTHON} Raspberry Pi temperature sensor}
-\newacronym{PWTS}{PWTS}{\gls{MICROPYTHON} wemos temperature sensor}
-\newacronym{QDSL}{QDSL}{quoted \acrshort{DSL}}
-\newacronym{RAM}{RAM}{random-access memory}
-\newacronym{RFID}{RFID}{radio-frequency identification}
-\newacronym{RTOS}{RTOS}{real-time \acrshort{OS}}
-\newacronym{RTS}{RTS}{run-time system}
-\newacronym{SDS}{SDS}{shared data source}
-\newacronym{SN}{SN}{sensor network}
-\newacronym{SLOC}{SLOC}{source lines of code}
-\newacronym{TH}{TH}{Template \gls{HASKELL}}
-\newacronym{TCP}{TCP}{transmission control protocol}
-\newacronym{TOP}{TOP}{task-oriented programming}
-\newacronym{TOSD}{TOSD}{task-oriented software development}
-\newacronym{TRS}{TRS}{term rewriting system}
-\newacronym{TTH}{TTH}{typed \acrlong{TH}}
-\newacronym{TVOC}{TVOC}{total volatile organic compounds}
-\newacronym{UI}{UI}{user interface}
-\newacronym{UOD}{UoD}{universe of discourse}
-\newacronym{UOG}{UoG}{University of Glasgow}
+% Acronym
+\newcommand{\myacronym}[4][]{%
+% \newacronym[type=\glsdefaulttype,#1]{#2}{#3}{#4}
+ \newacronym[#1]{#2}{#3}{#4}
+}
+\myacronym{3COWS}{3COWS}{The three ``CO'' (Composability, Comprehensibility, Correctness) winter school}
+\myacronym{ADC}{ADC}{analog-to-digital converter}
+\myacronym{ADT}{ADT}{algebraic data type}
+\myacronym{API}{API}{application programming interface}
+\myacronym{ARDSL}{ARDSL}{\gls{ARDUINO} \acrshort{DSL}}
+\myacronym{BLE}{BLE}{Bluetooth low energy}
+\myacronym{CEFP}{CEFP}{central European summer school of \acrlong{FP}}
+\myacronym{CRS}{CRS}{\gls{CLEAN} Raspberry Pi system}
+\myacronym{CRTS}{CRTS}{\gls{CLEAN} Raspberry Pi temperature sensor}
+\myacronym{CWS}{CWS}{\gls{CLEAN} \gls{WEMOS} system}
+\myacronym{CWTS}{CWTS}{\gls{CLEAN} \gls{WEMOS} temperature sensor}
+\myacronym{DHT}{DHT}{digital humidity and temperature}
+\myacronym{DSL}{DSL}{domain-specific language}
+\myacronym{ECO2}{eCO\textsubscript{2}}{equivalent carbon dioxide}
+\myacronym{EDSL}{eDSL}{embedded \acrlong{DSL}}
+\myacronym{FP}{FP}{functional programming}
+\myacronym{FRP}{FRP}{functional reactive programming}
+\myacronym{GADT}{GADT}{generalised \acrshort{ADT}}
+\myacronym{GHC}{GHC}{Glasgow \gls{HASKELL} Compiler}
+\myacronym{GPIO}{GPIO}{general-purpose \acrlong{IO}}
+\myacronym{GPL}{GPL}{general-purpose language}
+\myacronym{GRS}{GRS}{graph rewriting system}
+\myacronym{GUI}{GUI}{graphical \acrlong{UI}}
+\myacronym{HOAS}{HOAS}{high-order abstract syntax}
+\myacronym{IOT}{IoT}{internet of things}
+\myacronym{IDE}{IDE}{integrated development environment}
+\myacronym{IO}{IO}{input/output}
+\myacronym{IR}{IL}{intermediate representation}
+\myacronym{LEAN}{LEAN}{language of East-Anglia and Nijmegen}
+\myacronym{LED}{LED}{light-emitting diode}
+\myacronym{MCU}{MCU}{microcontroller unit}
+\myacronym{OLED}{OLED}{organic \acrlong{LED}}
+\myacronym{OS}{OS}{operating system}
+\myacronym{OTA}{OTA}{over-the-air}
+\myacronym{PIR}{PIR}{passive infrared}
+\myacronym{PRS}{PRS}{\gls{PYTHON} Raspberry Pi system}
+\myacronym{PWS}{PWS}{\gls{MICROPYTHON} \gls{WEMOS} system}
+\myacronym{PRTS}{PRTS}{\gls{PYTHON} Raspberry Pi temperature sensor}
+\myacronym{PWTS}{PWTS}{\gls{MICROPYTHON} \gls{WEMOS} temperature sensor}
+\myacronym{QDSL}{QDSL}{quoted \acrshort{DSL}}
+\myacronym{RAM}{RAM}{random-access memory}
+\myacronym{RFID}{RFID}{radio-frequency identification}
+\myacronym{RTOS}{RTOS}{real-time \acrshort{OS}}
+\myacronym{RTS}{RTS}{run-time system}
+\myacronym{SDS}{SDS}{shared data source}
+\myacronym{SN}{SN}{sensor network}
+\myacronym{SLOC}{SLOC}{source lines of code}
+\myacronym{TH}{TH}{Template \gls{HASKELL}}
+\myacronym{TCP}{TCP}{transmission control protocol}
+\myacronym{TOP}{TOP}{task-oriented programming}
+\myacronym{TOSD}{TOSD}{task-oriented software development}
+\myacronym{TRS}{TRS}{term rewriting system}
+\myacronym{TTH}{TTH}{typed \acrlong{TH}}
+\myacronym{TVOC}{TVOC}{total volatile organic compounds}
+\myacronym{UI}{UI}{user interface}
+\myacronym{UOD}{UoD}{universe of discourse}
+\myacronym{UOG}{UoG}{University of Glasgow}
% Glossaries
\newglossaryentry{MTASK}{%
}
\newglossaryentry{TOPHAT}{%
name=TopHat,
- description={is a \acrshort{TOP} language designed to formally capture the essence of \gls{TOP}}.
+ description={is a \acrshort{TOP} language designed to formally capture the essence of \gls{TOP}}
}
\newglossaryentry{CLEAN}{%
name=Clean,
}
\newglossaryentry{MQTT}{
name=MQTT,
- description={(originally MQ Telemetry Transport) is a publish-subscribe network protocol designed for resource constrained devices}
+ description={(MQ Telemetry Transport) is a publish-subscribe network protocol designed for resource constrained devices}
+}
+\newglossaryentry{WEMOS}{
+ name=WEMOS,
+ description={is a popular ESP8266 microprocessor based prototyping platform supporting \gls{ARDUINO}.}
}
\documentclass[../thesis.tex]{subfiles}
+\input{subfilepreamble}
+
\begin{document}
-\ifSubfilesClassLoaded{
- \pagenumbering{arabic}
-}{}
\chapter{Introduction}%
\label{chp:introduction}
-%\setlength{\epigraphwidth}{.5\textwidth}%
-%\epigraphhead[30]{
-% A \textbf{rhapsody} in music is a one-movement work that is episodic yet integrated, free-flowing in structure, featuring a range of highly contrasted moods, colour, and tonality. An air of spontaneous inspiration and a sense of improvisation make it freer in form than a set of variations.
-%}{%
-% Wikipedia~\citep{wikipedia_contributors_rhapsody_2022}
-%}%
-The sheer number of connected devices around us is increasing exponentially.
-All these devices are equipped with processors, sensors, actuators, communication interfaces and much more.
-They
-The one thing they all have in common
-All these connected devices are driven by software and communicate with eachother, sense and interact with the world.
-This thesis is about \ldots
-\todo[inline]{introduction}
+
+\begin{chapterabstract}
+ The sheer number of connected devices around us is mind boggling and seems increases exponentially for many years.
+ In 2022, there is an estimated number of 13.4 billion of devices connected that sense, act or otherwise interact with the world\footnote{\url{https://transformainsights.com/research/tam/market}, accessed on: \formatdate{2022}{10}{13}}.
+ These devices, together with the networks that provide the communication, the servers realising the back end and the devices in our pockets are called the \gls{IOT}.
+ \Gls{IOT} systems can be seen as layered systems, where each layer is powered by different types of computers; and programming languages and paradigms.
+ Thes thesis shows a novel way of orchestrating these brobdingnagian systems using the \gls{TOP} paradigm.
+ It does so by giving a proof-of-concept implementation for a \gls{TOP} system specifically designed for the \gls{IOT}: \gls{MTASK}.
+ At the core of the \gls{MTASK} system is a \gls{DSL}, embedded in the general purpose \gls{TOP} system \gls{ITASK}.
+ Using the \gls{MTASK} system, all layers of an \gls{IOT} system can be programmed from a single declarative specification.
+
+ This chapter provides the required background material, detail regarding the contributions and a reading guide.
+\end{chapterabstract}
+\todo{Introduction in the abstract doen zoals nu?}
\section{Internet of Things}
-\todo[inline]{add more citations and rewrite to make modern}
The \gls{IOT} is growing rapidly and it is changing the way people and machines interact with the world.
While the term \gls{IOT} briefly gained interest around 1999 to describe the communication of \gls{RFID} devices~\citep{ashton_internet_1999,ashton_that_2009}, it probably already popped up halfway the eigthies in a speech by \citet{peter_t_lewis_speech_1985}:
Today, the \gls{IOT} is the term for a system of devices that sense the environment, act upon it and communicate with each other and the world.
These connected devices are already in everyone's household in the form of smart electricity meters, smart fridges, smartphones, smart watches, home automation, \etc.
-When describing \gls{IOT} systems, a layered, or tiered architecture is often used to compartmentalize the technology.
-The number of tiers heavily depends on the complexity of the model but for the intents and purposes of the thesis, the four layer architecture shown in \cref{fig:iot-layers} is used.
+When describing \gls{IOT} systems layered---or tiered---architecture is often used to compartmentalize the technology.
+The number of tiers heavily depends on the required complexity of the model but for the intents and purposes of the thesis, the four layer architecture shown in \cref{fig:iot-layers} is used.
\begin{figure}[ht]
\centering
\includestandalone{iot-layers}
- \caption{The four layered \gls{IOT} architecture.}%
+ \caption{A four-layer \gls{IOT} architecture.}%
\label{fig:iot-layers}
\end{figure}
-\begin{description}
- \item[Presentation layer] This presentation layer provides the interface between the user and the \gls{IOT} application.
- For example, in home automation, this is often implemented as a web interface or a mobile app.
- \item[Application layer]
- Servers often power the application layer, by providing the data storage,
- One of its goals is to provide the \gls{API}, interfaces and data storage
- \item[Network layer] connects all layers together.
- In many applications this may be implemented using conventional networking techniques such as WiFi or wire networks.
- However, recently, networks tailored to the needs of \gls{IOT} applications have been increasingly popular such as \gls{BLE}, LoRa, ZigBee or LTE-M.
- \item[Perception layer], also called edge layer, collects the data, interacts with the environment and consists of (edge) devices equipped with various sensors and actuators.
- As a special type of device, it may also contain a \gls{SN}.
- A \gls{SN} is a collection of sensors connected by a mesh network or central hub.
-\end{description}
+The presentation layer provides the interface between the user and the \gls{IOT} application.
+For example, in home automation, this is a web interface or a mobile app used on the phone or a mounted tablet to interact with the edge devices.
+
+The application layer provides the \glspl{API}, interfaces and data storage.
+In home automation, this would be the cloud service or local server.
-The devices are a large heterogeneous collection of different platforms, protocols and languages resulting in impedance problems or semantic friction between layers~\citep{ireland_classification_2009}.
-Furthermore, the perception layer often is a heterogeneous collections of microcontrollers as well, each having their own peculiarities, language of choice and hardware interfaces.
-The hardware needs to be cheap, small-scale and energy efficient.
-As a result, the \glspl{MCU} used to power these devices do not have a lot of computational power, a soup\c{c}on of memory, and little communication bandwidth.
+All layers are connected using the network layer.
+In many applications this is implemented using conventional networking techniques such as WiFi or wired networks.
+However, networks and layers on top of itt tailored to the needs of \gls{IOT} applications have been increasingly popular such as \gls{BLE}, LoRa, ZigBee, LTE-M, or \gls{MQTT}.
+
+The perception layer---also called edge layer---collects the data, interacts with the environment, and consists of (edge) devices equipped with various sensors and actuators.
+%As a special type of device, it may also contain a \gls{SN}.
+%A \gls{SN} is a collection of sensors connected by a mesh network or central hub.
+In home automation this layer consists of all the microprocessors in the sensors, for example in the smart lightbulbs, actuators to open doors and sensors.
+
+Spanning all layers, the devices are a large heterogeneous collection of different platforms, protocols, paradigms and programming languages resulting in impedance problems or semantic friction between layers~\citep{ireland_classification_2009}.
+Furthermore, specifically the perception layer often is a heterogeneous collections of microprocessors in itself as well, each having their own peculiarities, language of choice and hardware interfaces.
+As the hardware needs to be cheap, small-scale, and energy efficient, the \glspl{MCU} used to power these devices do not have a lot of computational power, only a soup\c{c}on of memory, and little communication bandwidth.
Typically the devices do not run a full fledged \gls{OS} but a compiled firmware.
This firmware is often written in an imperative language that needs to be flashed to the program memory.
Program memory typically is flash based and only lasts a couple of thousand writes before it wears out.
-While devices are getting a bit faster, smaller, and cheaper, they keep these properties to an extent.
-The properties of the device greatly reduce the flexibility for dynamic systems where tasks are created on the fly, executed on demand and require parallel execution.
-\todo{\gls{OTA} benoemen?}
+While devices are getting a bit faster, smaller, and cheaper, they keep these properties to an extent, greatly reducing the flexibility for dynamic systems where tasks are created on the fly, executed on demand, or require parallel execution.
These problems can be mitigated by dynamically sending code to be interpreted to the \gls{MCU}.
With interpretation, a specialized interpreter is flashed in the program memory once that receives the program code to execute at runtime.
%weiser_computer_1991
-\section{Domain-specific languages}
+\section{\texorpdfstring{\Acrlongpl{DSL}}{Domain-specific languages}}
% General
Programming languages can be divided up into two categories: \glspl{DSL}\footnote{Historically this has been called DSEL as well.} and \glspl{GPL}~\citep{fowler_domain_2010}.
Where \glspl{GPL} are not made with a demarcated area in mind, \glspl{DSL} are tailor-made for a specific domain.
Unfortunately it also means that they need to develop a compiler or interpreter for the language to be usable making standalone \glspl{DSL} costly to create.
Examples of standalone \glspl{DSL} are regular expressions, make, yacc, XML, SQL, \etc.
-A dichotomous approach is embeddding the \gls{DSL} in a host language, i.e.\ \glspl{EDSL}~\citep{hudak_modular_1998}.
+A dichotomous approach is embedding the \gls{DSL} in a host language, i.e.\ \glspl{EDSL}~\citep{hudak_modular_1998}.
By defining the language as constructs in the host language, much of the machinery is inherited and the cost of creating embedded languages is very low.
There is more linguistic reuse~\cite{krishnamurthi_linguistic_2001}.
There are however two sides to the this coin.
Furthermore, errors shown to the programmer may be larded with host language errors, making it difficult for a non-expert of the host language to work with the \gls{DSL}.
\subsection{Heterogeneity and homogeneity}
-Tratt applied a notion from metaprogramming~\citep{sheard_accomplishments_2001} to \glspl{EDSL} to define homogeneity and heterogeneity of \glspl{EDSL} as follows~\citep{tratt_domain_2008}:
+\Citet{tratt_domain_2008} applied a notion from metaprogramming~\citep{sheard_accomplishments_2001} to \glspl{EDSL} to define homogeneity and heterogeneity of \glspl{EDSL} as follows:
+
\begin{quote}
- \emph{a homogeneous system is one where all the components are specifically designed to work with each other, whereas in heterogeneous systems at least one of the components is largely, or completely, ignorant of the existence of the other parts of the system.}
+ A homogeneous system is one where all the components are specifically designed to work with each other, whereas in heterogeneous systems at least one of the components is largely, or completely, ignorant of the existence of the other parts of the system.
\end{quote}
+
Homogeneous \glspl{EDSL} are therefore languages that are solely defined as an extension to their host language.
They often restrict features of the host language to provide a safer interface or capture an idiomatic pattern in the host language for reuse.
The difference between a library and a homogeneous \glspl{EDSL} is not always clear.
Examples of homogeneous \glspl{EDSL} are libraries such as ones for sets, \glspl{GUI} creation, LISP's macro system, \etc.
On the other hand, heterogeneous \glspl{EDSL} are languages that are not executed in the host language.
-For example, Elliott et al.\ describe the language Pan, for which the final representation in the host language is a compiler that will, when executed, generate code for a completely different target platform~\citep{elliott_compiling_2003}.
-In fact, \gls{ITASK} and \gls{MTASK} are both heterogeneous \glspl{EDSL}\todo{reference next section?}.
+For example, \citep{elliott_compiling_2003} describe the language Pan, for which the final representation in the host language is a compiler that will, when executed, generate code for a completely different target platform.
+In fact, \gls{ITASK} and \gls{MTASK} are both heterogeneous \glspl{EDSL} and \gls{MTASK} specifically is a compiling \gls{DSL}.
\section{Task-oriented programming}
\Gls{TOP} is a declarative programming paradigm designed to model interactive systems~\citep{plasmeijer_task-oriented_2012}.
\end{figure}
\begin{description}
- \item[Presentation layer: \gls{UI}]
+ \item[Presentation layer (\gls{UI})]
The \gls{UI} of the system is automatically generated from the representation of the type.
% For instance, \gls{TOP} languages implemented in an \gls{FP} language often use generic programming or template metaprogramming to automatically achieve this.
% \Gls{TOP} languages embedded in imperative programming languages may use introspection\todo{Do I want this sentence here?}.
Even though the \gls{UI} is generated from the structure of the datatypes, in practical \gls{TOP} systems it can be tweaked afterwards to suit the specific needs of the application.
- \item[Business layer: tasks]
+ \item[Business layer (tasks):]
A task is an abstract representation of a piece of work that needs to be done.
It provides an intuitive abstraction over work in the real world.
Just as with real-life tasks and workflow, tasks can be combined in various ways such as in parallel or in sequence.
Furthermore, a task is observable which means it is possible to observe a---partial---result during execution and act upon it by for example starting new tasks.
Examples of tasks are filling in a form, sending an email, reading a sensor or even doing a physical task.
- \item[Resource access: \glspl{SDS}]
+ \item[Resource access (\glspl{SDS}):]
Tasks can communicate using task values but this imposes a problem in many collaboration patterns where tasks that are not necessarily related need to share data.
Tasks can also share data using \glspl{SDS}, an abstraction over any data.
An \gls{SDS} can represent typed data stored in a file, a chunk of memory, a database \etc.
\Glspl{SDS} can also represent external impure data such as the time, random numbers or sensory data.
Similar to tasks, transformation and combination of \glspl{SDS} is possible.
- \item[\Gls{UOD}: programming language]
+ \item[\Gls{UOD} (programming language):]
The \gls{UOD} from the business layer is explicitly and separately modelled by the relations that exist in the functions of the host language.
\end{description}
\todo[inline]{uitbreiden}
On Wikipedia, a rhapsody is defined as follows~\citep{wikipedia_contributors_rhapsody_2022}:
\begin{quote}
- \emph{A \textbf{rhapsody} in music is a one-movement work that is episodic yet integrated, free-flowing in structure, featuring a range of highly contrasted moods, colour, and tonality. An air of spontaneous inspiration and a sense of improvisation make it freer in form than a set of variations.}
+ A \textbf{rhapsody} in music is a one-movement work that is episodic yet integrated, free-flowing in structure, featuring a range of highly contrasted moods, colour, and tonality. An air of spontaneous inspiration and a sense of improvisation make it freer in form than a set of variations.
\end{quote}
-
This thesis follows the tradition and consists of three movements that are episodic yet integrated, a purely functional rhapsody.
\Cref{prt:dsl} is about \gls{EDSL} techniques, \cref{prt:top} elaborates on \gls{TOP} for the \gls{IOT} and \cref{prt:tvt} compares traditional tiered \gls{IOT} architectures to a tierless architectures such as \gls{TOP}.
The movements are readable independently if the reader is familiarised with the background material provided in \cref{chp:introduction}.
The thesis wraps up with \cref{chp:conclusion} that provides a conclusion and an outlook on future work.
\subsection*{\nameref{prt:dsl}}
-This movement is a cumulative---paper-based---movement that focusses on techniques for embedding \glspl{DSL} in \gls{FP} lanugages.
-After reading the first chapter, subsequent chapters in this movement are readable as independently.
+This movement is a cumulative---paper-based---movement that focusses on techniques for embedding \glspl{DSL} in \gls{FP} languages.
+After reading the first chapter, subsequent chapters in this movement are readable independently.
\subsubsection*{\fullref{chp:dsl_embedding_techniques}}
This chapter shows the basic \gls{DSL} embedding techniques and compares the properties of several embedding methods.
This chapter is not based on a paper and written as a extra background material for the subsequent chapters in the movement.
-\subsubsection*{\fullref{chp:classy_deep_embedding}}
-This chapter is based on the paper: \emph{Deep Embedding with Class}~\todo{cite when published}.
+\subsubsection*{\fullref{chp:classy_deep_embedding}}
+This chapter is based on the paper: \bibentry{lubbers_deep_2022}\todo{change in-press when published}.
-During a Master's thesis supervision~\citep{amazonas_cabral_de_andrade_developing_2018}, focussing on an early version of \gls{MTASK}, a seed was planted for a novel deep embedding technique for \glspl{DSL} where the resulting language is extendible both in constructs and in interpretation using type classes and existential data types.
+While supervising \citeauthor{amazonas_cabral_de_andrade_developing_2018}'s \citeyear{amazonas_cabral_de_andrade_developing_2018} Master's thesis, focussing on an early version of \gls{MTASK}, a seed was planted for a novel deep embedding technique for \glspl{DSL} where the resulting language is extendible both in constructs and in interpretation using type classes and existential data types.
Slowly the ideas organically grew to form the technique shown in the paper.
The research from this paper and writing the paper was solely performed by me.
\Cref{sec:classy_reprise} was added after publication and contains a (yet) unpublished extension of the embedding technique.
\subsubsection*{\fullref{chp:first-class_datatypes}}
-This chapter is based on the paper: \emph{First-Class Data Types in Shallow Embedded Domain-Specific Languages using Metaprogramming}~\todo{cite when accepted}.
-It shows how to inherit data types in \glspl{EDSL} using metaprogramming.
+This chapter is based on the paper: \bibentry{lubbers_first-class_2022}\todo{change when accepted}.
+
+It shows how to inherit data types from the host language in \glspl{EDSL} using metaprogramming.
The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer in which we discussed and refined the ideas.
\subsection*{\nameref{prt:top}}
-This part is a monograph focussing on \glspl{TOP} for the \gls{IOT}.
-Therefore, the chapters depend on eachother and are best read in order.
+This part is a monograph focussing on \glspl{TOP} for the \gls{IOT} and hence are the chapters best read in order.
The monograph is compiled from the following papers and revised lecture notes.
+\newcommand{\citeentry}[1]{\begin{NoHyper}\bibentry{#1}\end{NoHyper}. \citep{#1}}
\begin{itemize}
- \item \bibentry{koopman_task-based_2018}.
+ \item \citeentry{koopman_task-based_2018}
This was the initial \gls{TOP}/\gls{MTASK} paper.
- Pieter Koopman wrote it but I helped with the software and research.
- \item \bibentry{lubbers_task_2018}.
+ Pieter Koopman wrote it, I helped with the software and research.
+ \item \citeentry{lubbers_task_2018}
This paper was an extension of my Master's thesis~\citep{lubbers_task_2017}.
It shows how a simple imperative variant of \gls{MTASK} was integrated with \gls{ITASK}.
While the language was a lot different than later versions, the integration mechanism is still used in \gls{MTASK} today.
-
The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer in which we discussed and refined the ideas.
- \item \bibentry{lubbers_multitasking_2019}.
+ \item \citeentry{lubbers_multitasking_2019}
This paper was a short paper on the multitasking capabilities of \gls{MTASK} in contrast to traditional multitasking methods for \gls{ARDUINO}.
- \item \emph{Simulation of a Task-Based Embedded Domain Specific Language for the Internet of Things}~\todo{cite when published}
+ The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer.
+ \item \citeentry{koopman_simulation_2018}\todo{change when published}
These revised lecture notes are from a course on the \gls{MTASK} simulator was provided at the 2018 CEFP/3COWS winter school in Ko\v{s}ice, Slovakia.
- Pieter Koopman wrote and taught it though I helped with the software and research.
- \item \emph{Writing Internet of Things applications with Task Oriented Programming}~\todo{cite when published}
+ Pieter Koopman wrote and taught it, I helped with the software and research.
+ \item \citeentry{lubbers_writing_2019}\todo{change when published}
These revised lecture notes are from a course on programming in \gls{MTASK} provided at the 2019 CEFP/3COWS summer school in Budapest, Hungary.
- Pieter prepared half of the lecture. I wrote the lecture notes, prepared the other half of the lecture, the assignments and practical session.
- \item \bibentry{lubbers_interpreting_2019}.
+ Pieter Koopman prepared and taught half of the lecture and supervised the practical session.
+ I taught the other half of the lecture, wrote the lecture notes, made the assignments and supervised the practical session.
+ \item \citeentry{lubbers_interpreting_2019}
- This paper showed an implementation for \gls{MTASK} for microcontrollers in the form of a compilation scheme and informal semantics description.
+ This paper shows an implementation for \gls{MTASK} for microcontrollers in the form of a compilation scheme and informal semantics description.
- The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer in which we discussed and refined the ideas.
- \item \emph{Reducing the Power Consumption of IoT with Task-Oriented Programming}~\todo{cite when published}
+ The research in this paper and writing the paper was performed by me, though there were weekly meetings with Pieter Koopman and Rinus Plasmeijer.
+ \item \citeentry{crooijmans_reducing_2022}\todo{change when published}
This paper shows how to create a scheduler so that devices running \gls{MTASK} tasks can go to sleep more automatically.
Furthermore, it shows how to integrate hardware interrupts into \gls{MTASK}.
- The research was carried out by Sjoerd Crooijmans during his Master's thesis~\citep{crooijmans_reducing_2021}.
+ The research was carried out by \citet{crooijmans_reducing_2021} during his Master's thesis.
I did the daily supervision and helped with the research, Pieter Koopman was the formal supervisor and wrote most of the paper.
- \item \emph{Asynchronous Shared Data Sources}~\todo{cite when accepted}
-
- \todo[inline]{This paper could in theory be dropped in favour of being done sooner with the thesis}
+ \item \emph{Green Computing for the Internet of Things}\todo{change when published}
- Asynchronous \glspl{SDS} are used in the current \gls{ITASK} system and allow bigger \gls{IOT} devices such as raspberry pi's to be used in a tierless \gls{ITASK} system.
- The example application shown in \cref{prt:tvt} heavily uses asynchronous \glspl{SDS}.
- This paper shows how to lift \glspl{SDS} to operate asynchronously independent of \gls{ITASK} or another \gls{TOP} implementation.
+ These revised lecture notes are from a course on sustainable programming using \gls{MTASK} provided at the 2022 SusTrainable summer school in Rijeka, Croatia.
- The initial research was carried out by Haye B\"ohm during his Master's thesis~\citep{bohm_asynchronous_2019}.
- I did the daily supervision and helped with the research, Pieter Koopman and Rinus Plasmeijer were the formal supervisors.
- I extended and generalised the research and wrote the paper.
- \item \emph{Green Computing for the Internet of Things}~\todo[inline]{cite when done}
-
- These revised lecture notes are from a course on sustainable programming using \gls{MTASK} provided at the 2022 Sustrainable summer school in Rijeka, Croatia.
-
- Pieter prepared half of the lecture and wrote the introduction.
- I wrote the middle part of the lecture notes, prepared the other half of the lecture, the assignments and the practical session.
-\end{itemize}
-
-The movement is made up out of the following chapters
-\todo[inline]{preliminary}
-
-\begin{itemize}
- \item The mTask language (includes informal semantics)
- \begin{itemize}
- \item Expressions
- \item Functions
- \item Tasks
- \item Shares
- \item Peripherals
- \end{itemize}
- \item Interpretations/views/backends\todo{decide on terminology}
- \item Green computing
- \item Integration with iTask
- \item Implementation (based on IFL19 paper)
- \item TOP for IoT beyond microprocessors
+ Pieter prepared and taught a quarter of the lecture and supervised the practical session.
+ I prepared and taught the other three quarters of the lecture, made the assignments and supervised the practical session\todo{writing contribution}.
\end{itemize}
\subsection*{\nameref{prt:tvt}}
-These chapters focus on comparing traditional tiered architectures to tierless architectures and are based on a single journal paper that extended on a conference paper.
-The conference paper was partly funded by the Radboud-Glasgow Collaboration Fund.
-It does both a qualitative and a quantitative four-way comparison of a smart campus application.
-
-The research in these papers and writing them was performed by all authors.
-I created the server application, the \gls{CLEAN}/\gls{ITASK}/\gls{MTASK} implementation (\acrshort{CWS}) and the \gls{CLEAN}/\gls{ITASK} implementation (\acrshort{CRS})
-Adrian Ramsingh created the micropython implementation (\acrshort{PWS}), the original python implementation (\acrshort{PRS}) and the server application were created by Jeremy Singer, Dejice Jacob and Kristian Hentschel~\citep{hentschel_supersensors:_2016}.
+This chapter is based on the journal paper: \citeentry{lubbers_could_2022}\footnote{The journal paper is an extension of the conference article: \citeentry{lubbers_tiered_2020}\footnotemark{}}.
+\footnotetext{This paper was partly funded by the Radboud-Glasgow Collaboration Fund.}
-\begin{itemize}
- \item \bibentry{lubbers_tiered_2020}.
- \item \emph{Could Tierless Languages Reduce IoT Development Grief?}~\todo[inline]{cite when accepted}
-\end{itemize}
-
-\newcounter{secondauthorcnt}
-\newcounter{underreviewcnt}
-\newcounter{plannedcnt}
-\newcounter{publicationscnt}
-\newcommand{\secondauthor}{\textsuperscript{$\ast$}\stepcounter{secondauthorcnt}}
-\newcommand{\underreview}{\textsuperscript{$\dagger$}\stepcounter{underreviewcnt}}
-\newcommand{\planned}{\textsuperscript{$\ddagger$}\stepcounter{plannedcnt}}
-
-\subsection{List of publications}
-\begin{enumerate}
- \item \secondauthor{}
- A Task-Based DSL for Microcomputers
-
- P. Koopman\footnote{\orcid{0000-0002-3688-0957}}, M. Lubbers\footnote{\orcid{0000-0002-4015-4878}}, and R. Plasmeijer (RWDSL 2018)~\citep{koopman_task-based_2018}.
- \item Task Oriented Programming and the Internet of Things
-
- M. Lubbers, P. Koopman, and R. Plasmeijer (IFL 2018)~\citep{lubbers_task_2017} (extension of Master's thesis~\citep{lubbers_task_2018}).
- \item Multitasking on Microcontrollers using Task Oriented Programming
-
- M. Lubbers, P. Koopman, and R. Plasmeijer (MIPRO/4COWS 2019)~\citep{lubbers_multitasking_2019}.
- \item \secondauthor{}
- Simulation of a Task-Based Embedded Domain Specific Language for the Internet of Things
-
- P. Koopman, M. Lubbers, and R. Plasmeijer (CEFP/3COWS 2018).
- \item Writing Internet of Things applications with Task Oriented Programming
-
- M. Lubbers, P. Koopman, and R. Plasmeijer (CEFP/3COWS 2019).
- \item Interpreting Task Oriented Programs on Tiny Computers
-
- M. Lubbers, P. Koopman, and R. Plasmeijer (IFL 2019)~\citep{lubbers_interpreting_2019}.
- \item Tiered versus Tierless IoT Stacks: Comparing Smart Campus Software Architectures
-
- M. Lubbers, P. Koopman, A. Ramsingh\footnote{\orcid{0000-0003-3501-902X}}, J. Singer\footnote{\orcid{0000-0001-9462-6802}}, and P. Trinder\footnote{\orcid{0000-0003-0190-7010}} (IoT 2020)~\citep{lubbers_tiered_2020}.
-
- % in press
- \item Deep Embedding with Class
+It compares programming traditional tiered architectures to tierless architectures by showing a qualitative and a quantitative four-way comparison of a smart campus application.
- M. Lubbers (TFP 2022).
- \item \secondauthor{}
- Reducing the Power Consumption of IoT with Task-Oriented Programming
-
- S. Crooijmans, M. Lubbers, and P. Koopman (TFP 2022).
-
- %Under review
- \item \underreview{} Could Tierless Languages Reduce IoT Development Grief?
-
- M. Lubbers, P. Koopman, A. Ramsingh, J. Singer, and P. Trinder (ACM TIOT) (extension of~\citep{lubbers_tiered_2020}).
- \item \secondauthor\underreview{}
- Strongly-Typed Multi-View Stack-Based Computations
-
- M. Lubbers and P. Koopman (IFL 2022 under review).
- \item \underreview{} First-Class Data Types in Shallow Embedded Domain-Specific Languages using Metaprogramming
-
- M. Lubbers, P. Koopman, and R. Plasmeijer (IFL 2022 under review).
- \item \underreview{} Asynchronous Shared Data Sources
-
- M. Lubbers, H. Böhm, P. Koopman, and R. Plasmeijer (IFL 2022 under review).
-
- %Planned
- \item \planned{} Green Computing for the Internet of Things
-
- M. Lubbers, P. Koopman (Sustrainable 2022 planned).
-
- \setcounter{publicationscnt}{\value{enumi}}
-\end{enumerate}
-
-There are \thepublicationscnt{} publications of which \thesecondauthorcnt{} I'm second author, \theunderreviewcnt{} are under review and \theplannedcnt{} are planned.
+Writing the paper was performed by all authors.
+I created the server application, the \gls{CLEAN}/\gls{ITASK}/\gls{MTASK} implementation (\acrshort{CWS}) and the \gls{CLEAN}/\gls{ITASK} implementation (\acrshort{CRS})
+Adrian Ramsingh created the \gls{MICROPYTHON} implementation (\acrshort{PWS}), the original \gls{PYTHON} implementation (\acrshort{PRS}) and the server application were created by Jeremy Singer, Dejice Jacob and Kristian Hentschel~\citep{hentschel_supersensors:_2016}.
\input{subfilepostamble}
\end{document}
series = {{PPDP} '12},
title = {Task-{Oriented} {Programming} in a {Pure} {Functional} {Language}},
isbn = {978-1-4503-1522-7},
- url = {https://doi.org/10.1145/2370776.2370801},
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}},
series = {{POPL} '96},
title = {Revisiting {Catamorphisms} over {Datatypes} with {Embedded} {Functions} (or, {Programs} from {Outer} {Space})},
isbn = {0-89791-769-3},
- url = {https://doi.org/10.1145/237721.237792},
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}},
series = {{PLDI} '88},
title = {Higher-{Order} {Abstract} {Syntax}},
isbn = {0-89791-269-1},
- url = {https://doi.org/10.1145/53990.54010},
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}},
series = {{ICFP} '08},
title = {Parametric {Higher}-{Order} {Abstract} {Syntax} for {Mechanized} {Semantics}},
isbn = {978-1-59593-919-7},
- url = {https://doi.org/10.1145/1411204.1411226},
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}},
address = {New York, NY},
title = {User-{Defined} {Types} and {Procedural} {Data} {Structures} as {Complementary} {Approaches} to {Data} {Abstraction}},
isbn = {978-1-4612-6315-9},
- url = {https://doi.org/10.1007/978-1-4612-6315-9_22},
abstract = {User-defined types (or modes) and procedural (or functional) data structures are complementary methods for data abstraction, each providing a capability lacked by the other. With user-defined types, all information about the representation of a particular kind of data is centralized in a type definition and hidden from the rest of the program. With procedural data structures, each part of the program which creates data can specify its own representation, independently of any representations used elsewhere for the same kind of data. However, this decentralization of the description of data is achieved at the cost of prohibiting primitive operations from accessing the representations of more than one data item. The contrast between these approaches is illustrated by a simple example.},
booktitle = {Programming {Methodology}: {A} {Collection} of {Articles} by {Members} of {IFIP} {WG2}.3},
publisher = {Springer New York},
series = {{PPDP} '06},
title = {Open {Data} {Types} and {Open} {Functions}},
isbn = {1-59593-388-3},
- url = {https://doi.org/10.1145/1140335.1140352},
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}},
series = {{ICFP} '98},
title = {Fold and {Unfold} for {Program} {Semantics}},
isbn = {1-58113-024-4},
- url = {https://doi.org/10.1145/289423.289457},
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}},
title = {Dynamic {Typing} in a {Statically} {Typed} {Language}},
volume = {13},
issn = {0164-0925},
- url = {https://doi.org/10.1145/103135.103138},
doi = {10.1145/103135.103138},
abstract = {Statically typed programming languages allow earlier error checking, better enforcement of diciplined programming styles, and the generation of more efficient object code than languages where all type consistency checks are performed at run time. However, even in statically typed languages, there is often the need to deal with datawhose type cannot be determined at compile time. To handle such situations safely, we propose to add a type Dynamic whose values are pairs of a value v and a type tag T where v has the type denoted by T. Instances of Dynamic are built with an explicit tagging construct and inspected with a type safe typecase construct.This paper explores the syntax, operational semantics, and denotational semantics of a simple language that includes the type Dynamic. We give examples of how dynamically typed values can be used in programming. Then we discuss an operational semantics for our language and obtain a soundness theorem. We present two formulations of the denotational semantics of this language and relate them to the operational semantics. Finally, we consider the implications of polymorphism and some implementation issues.},
number = {2},
title = {Abstract {Types} {Have} {Existential} {Type}},
volume = {10},
issn = {0164-0925},
- url = {https://doi.org/10.1145/44501.45065},
doi = {10.1145/44501.45065},
abstract = {Abstract data type declarations appear in typed programming languages like Ada, Alphard, CLU and ML. This form of declaration binds a list of identifiers to a type with associated operations, a composite “value” we call a data algebra. We use a second-order typed lambda calculus SOL to show how data algebras may be given types, passed as parameters, and returned as results of function calls. In the process, we discuss the semantics of abstract data type declarations and review a connection between typed programming languages and constructive logic.},
number = {3},
series = {{PPDP} '19},
title = {{TopHat}: {A} {Formal} {Foundation} for {Task}-{Oriented} {Programming}},
isbn = {978-1-4503-7249-7},
- url = {https://doi.org/10.1145/3354166.3354182},
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}},
series = {{TLDI} '12},
title = {Giving {Haskell} a {Promotion}},
isbn = {978-1-4503-1120-5},
- url = {https://doi.org/10.1145/2103786.2103795},
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}},
series = {Haskell '09},
title = {Unembedding {Domain}-{Specific} {Languages}},
isbn = {978-1-60558-508-6},
- url = {https://doi.org/10.1145/1596638.1596644},
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}},
address = {Cham},
title = {Functional {Programming} for {Domain}-{Specific} {Languages}},
isbn = {978-3-319-15940-9},
- url = {https://doi.org/10.1007/978-3-319-15940-9_1},
abstract = {Domain-specific languages are a popular application area for functional programming; and conversely, functional programming is a popular implementation vehicle for domain-specific languages—at least, for embedded ones. Why is this? The appeal of embedded domain-specific languages is greatly enhanced by the presence of convenient lightweight tools for defining, implementing, and optimising new languages; such tools represent one of functional programming's strengths. In these lectures we discuss functional programming techniques for embedded domain-specific languages; we focus especially on algebraic datatypes and higher-order functions, and their influence on deep and shallow embeddings.},
booktitle = {Central {European} {Functional} {Programming} {School}: 5th {Summer} {School}, {CEFP} 2013, {Cluj}-{Napoca}, {Romania}, {July} 8-20, 2013, {Revised} {Selected} {Papers}},
publisher = {Springer International Publishing},
file = {Gibbons - 2015 - Functional Programming for Domain-Specific Languag.pdf:/home/mrl/.local/share/zotero/storage/ARUBLFU6/Gibbons - 2015 - Functional Programming for Domain-Specific Languag.pdf:application/pdf},
}
-@incollection{lubbers_writing_2019,
- address = {Cham},
- title = {Writing {Internet} of {Things} applications with {Task} {Oriented} {Programming}},
- abstract = {The Internet of Things (IOT) is growing fast. In 2018, there was approximately one connected device per person on earth and the number has been growing ever since. The devices interact with the environment via different modalities at the same time using sensors and actuators making the programs parallel. Yet, writing this type of programs is difficult because the devices have little computation power and memory, the platforms are heterogeneous and the languages are low level. Task Oriented Programming (TOP) is a novel declarative programming language paradigm that is used to express coordination of work, collaboration of users and systems, the distribution of shared data and the human computer interaction. The mTask language is a specialized, yet full-fledged, multi-backend TOP language for IOT devices. With the bytecode interpretation backend and the integration with iTasks, tasks can be executed on the device dynamically. This means that —according to the current state of affairs— tasks can be tailor-made at run time, compiled to device-agnostic bytecode and shipped to the device for interpretation. Tasks sent to the device are fully integrated in iTasks to allow every form of interaction with the tasks such as observation of the task value and interaction with Shared Data Sources (SDSs). The application is —server and devices— are programmed in a single language, albeit using two embedded Domain Specific Languages (EDSLs).},
- language = {en},
- booktitle = {Central {European} {Functional} {Programming} {School}: 8th {Summer} {School}, {CEFP} 2019, {Budapest}, {Hungary}, {July} 17–21, 2019, {Revised} {Selected} {Papers}},
- publisher = {Springer International Publishing},
- author = {Lubbers, Mart and Koopman, Pieter and Plasmeijer, Rinus},
- year = {2019},
- pages = {51},
- file = {Lubbers - Writing Internet of Things applications with Task .pdf:/home/mrl/.local/share/zotero/storage/ILZIBYW5/Lubbers - Writing Internet of Things applications with Task .pdf:application/pdf},
-}
-
@mastersthesis{veen_van_der_mutable_2020,
address = {Nijmegen},
title = {Mutable {Collection} {Types} in {Shallow} {Embedded} {DSLs}},
title = {Maintaining {Separation} of {Concerns} {Through} {Task} {Oriented} {Software} {Development}},
volume = {10788},
isbn = {978-3-319-89718-9 978-3-319-89719-6},
- url = {http://link.springer.com/10.1007/978-3-319-89719-6_2},
abstract = {Task Oriented Programming is a programming paradigm that enhances ‘classic’ functional programming with means to express the coordination of work among people and computer systems, the distribution and control of data sources, and the human-machine interfaces. To make the creation process of such applications feasible, it is important to have separation of concerns. In this paper we demonstrate how this is achieved within the Task Oriented Software Development process and illustrate the approach by means of a case study.},
language = {en},
urldate = {2019-01-14},
title = {Supersensors: {Raspberry} {Pi} {Devices} for {Smart} {Campus} {Infrastructure}},
isbn = {978-1-5090-4052-0},
shorttitle = {Supersensors},
- url = {http://ieeexplore.ieee.org/document/7575844/},
doi = {10.1109/FiCloud.2016.16},
abstract = {We describe an approach for developing a campuswide sensor network using commodity single board computers. We sketch various use cases for environmental sensor data, for different university stakeholders. Our key premise is that supersensors—sensors with significant compute capability—enable more flexible data collection, processing and reaction. In this paper, we describe the initial prototype deployment of our supersensor system in a single department at the University of Glasgow.},
language = {en},
shorttitle = {Developing {Real} {Life}, {TOP} {Applications} for the {IOT}},
language = {en},
school = {Radboud University},
- author = {Amazonas Cabral De Andrade, Matheus},
+ author = {Amazonas Cabral de Andrade, Matheus},
year = {2018},
file = {Lubbers - prof. dr. dr.h.c. ir. M.J. Plasmeijer.pdf:/home/mrl/.local/share/zotero/storage/JXPEWS85/Lubbers - prof. dr. dr.h.c. ir. M.J. Plasmeijer.pdf:application/pdf},
}
title = {A {Shallow} {Embedded} {Type} {Safe} {Extendable} {DSL} for the {Arduino}},
volume = {9547},
isbn = {978-3-319-39110-6},
- url = {http://link.springer.com/10.1007/978-3-319-39110-6},
urldate = {2017-02-22},
booktitle = {Trends in {Functional} {Programming}},
publisher = {Springer International Publishing},
@inproceedings{cheney_lightweight_2002,
title = {A lightweight implementation of generics and dynamics},
- url = {http://dl.acm.org/citation.cfm?id=581698},
doi = {10.1145/581690.581698},
urldate = {2017-05-15},
booktitle = {Proceedings of the 2002 {ACM} {SIGPLAN} workshop on {Haskell}},
title = {A {Survey} of {Metaprogramming} {Languages}},
volume = {52},
issn = {0360-0300},
- url = {https://doi.org/10.1145/3354584},
doi = {10.1145/3354584},
abstract = {Metaprogramming is the process of writing computer programs that treat programs as data, enabling them to analyze or transform existing programs or generate new ones. While the concept of metaprogramming has existed for several decades, activities focusing on metaprogramming have been increasing rapidly over the past few years, with most languages offering some metaprogramming support and the amount of metacode being developed growing exponentially. In this article, we introduce a taxonomy of metaprogramming languages and present a survey of metaprogramming languages and systems based on the taxonomy. Our classification is based on the metaprogramming model adopted by the language, the phase of the metaprogram evaluation, the metaprogram source location, and the relation between the metalanguage and the object language.},
number = {6},
series = {Haskell '07},
title = {Why {It}'s {Nice} to {Be} {Quoted}: {Quasiquoting} for {Haskell}},
isbn = {978-1-59593-674-5},
- url = {https://doi.org/10.1145/1291201.1291211},
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}},
title = {Domain {Specific} {Language} {Implementation} via {Compile}-{Time} {Meta}-{Programming}},
volume = {30},
issn = {0164-0925},
- url = {https://doi.org/10.1145/1391956.1391958},
doi = {10.1145/1391956.1391958},
abstract = {Domain specific languages (DSLs) are mini-languages that are increasingly seen as being a valuable tool for software developers and non-developers alike. DSLs must currently be created in an ad-hoc fashion, often leading to high development costs and implementations of variable quality. In this article, I show how expressive DSLs can be hygienically embedded in the Converge programming language using its compile-time meta-programming facility, the concept of DSL blocks, and specialised error reporting techniques. By making use of pre-existing facilities, and following a simple methodology, DSL implementation costs can be significantly reduced whilst leading to higher quality DSL implementations.},
number = {6},
series = {Haskell '08},
title = {Making {Monads} {First}-{Class} with {Template} {Haskell}},
isbn = {978-1-60558-064-7},
- url = {https://doi.org/10.1145/1411286.1411300},
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}},
series = {Haskell '02},
title = {Template {Meta}-{Programming} for {Haskell}},
isbn = {1-58113-605-6},
- url = {https://doi.org/10.1145/581690.581691},
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}},
@article{hammond_automatic_2003,
title = {{AUTOMATIC} {SKELETONS} {IN} {TEMPLATE} {HASKELL}},
volume = {13},
- url = {https://doi.org/10.1142/S0129626403001380},
doi = {10.1142/S0129626403001380},
abstract = {This paper uses Template Haskell to automatically select appropriate skeleton implementations in the Eden parallel dialect of Haskell. The approach allows implementation parameters to be statically tuned according to architectural cost models based on source analyses. This permits us to target a range of parallel architecture classes from a single source specification. A major advantage of the approach is that cost models are user-definable and can be readily extended to new data or computation structures etc.},
number = {03},
series = {Haskell '12},
title = {Template {Your} {Boilerplate}: {Using} {Template} {Haskell} for {Efficient} {Generic} {Programming}},
isbn = {978-1-4503-1574-6},
- url = {https://doi.org/10.1145/2364506.2364509},
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}},
address = {Berlin, Heidelberg},
title = {Embedding a {Hardware} {Description} {Language} in {Template} {Haskell}},
isbn = {978-3-540-25935-0},
- url = {https://doi.org/10.1007/978-3-540-25935-0_9},
abstract = {Hydra is a domain-specific language for designing digital circuits, which is implemented by embedding within Haskell. Many features required for hardware specification fit well within functional languages, leading in many cases to a perfect embedding. There are some situations, including netlist generation and software logic probes, where the DSL does not fit exactly within the host functional language. A new solution to these problems is based on program transformations performed automatically by metaprograms in Template Haskell.},
booktitle = {Domain-{Specific} {Program} {Generation}: {International} {Seminar}, {Dagstuhl} {Castle}, {Germany}, {March} 23-28, 2003. {Revised} {Papers}},
publisher = {Springer Berlin Heidelberg},
address = {Berlin, Heidelberg},
title = {{DSL} {Implementation} in {MetaOCaml}, {Template} {Haskell}, and {C}++},
isbn = {978-3-540-25935-0},
- url = {https://doi.org/10.1007/978-3-540-25935-0_4},
abstract = {A wide range of domain-specific languages (DSLs) has been implemented successfully by embedding them in general purpose languages. This paper reviews embedding, and summarizes how two alternative techniques – staged interpreters and templates – can be used to overcome the limitations of embedding. Both techniques involve a form of generative programming. The paper reviews and compares three programming languages that have special support for generative programming. Two of these languages (MetaOCaml and Template Haskell) are research languages, while the third (C++) is already in wide industrial use. The paper identifies several dimensions that can serve as a basis for comparing generative languages.},
booktitle = {Domain-{Specific} {Program} {Generation}: {International} {Seminar}, {Dagstuhl} {Castle}, {Germany}, {March} 23-28, 2003. {Revised} {Papers}},
publisher = {Springer Berlin Heidelberg},
series = {{LFP} '86},
title = {Hygienic {Macro} {Expansion}},
isbn = {0-89791-200-4},
- url = {https://doi.org/10.1145/319838.319859},
doi = {10.1145/319838.319859},
booktitle = {Proceedings of the 1986 {ACM} {Conference} on {LISP} and {Functional} {Programming}},
publisher = {Association for Computing Machinery},
series = {{TLDI} '03},
title = {Scrap {Your} {Boilerplate}: {A} {Practical} {Design} {Pattern} for {Generic} {Programming}},
isbn = {1-58113-649-8},
- url = {https://doi.org/10.1145/604174.604179},
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}},
series = {{GPCE} 2014},
title = {{LibDSL}: {A} {Library} for {Developing} {Embedded} {Domain} {Specific} {Languages} in d via {Template} {Metaprogramming}},
isbn = {978-1-4503-3161-6},
- url = {https://doi.org/10.1145/2658761.2658770},
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}},
series = {Haskell '11},
title = {Embedded {Parser} {Generators}},
isbn = {978-1-4503-0860-1},
- url = {https://doi.org/10.1145/2034675.2034689},
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}},
series = {Haskell '14},
title = {Promoting {Functions} to {Type} {Families} in {Haskell}},
isbn = {978-1-4503-3041-1},
- url = {https://doi.org/10.1145/2633357.2633361},
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}},
series = {{IFL} 2018},
title = {A {Staged} {Embedding} of {Attribute} {Grammars} in {Haskell}},
isbn = {978-1-4503-7143-8},
- url = {https://doi.org/10.1145/3310232.3310235},
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}},
address = {Berlin, Heidelberg},
title = {Typed {Tagless} {Final} {Interpreters}},
isbn = {978-3-642-32202-0},
- url = {https://doi.org/10.1007/978-3-642-32202-0_3},
abstract = {The so-called `typed tagless final' approach of [6] has collected and polished a number of techniques for representing typed higher-order languages in a typed metalanguage, along with type-preserving interpretation, compilation and partial evaluation. The approach is an alternative to the traditional, or `initial' encoding of an object language as a (generalized) algebraic data type. Both approaches permit multiple interpretations of an expression, to evaluate it, pretty-print, etc. The final encoding represents all and only typed object terms without resorting to generalized algebraic data types, dependent or other fancy types. The final encoding lets us add new language forms and interpretations without breaking the existing terms and interpreters.},
booktitle = {Generic and {Indexed} {Programming}: {International} {Spring} {School}, {SSGIP} 2010, {Oxford}, {UK}, {March} 22-26, 2010, {Revised} {Lectures}},
publisher = {Springer Berlin Heidelberg},
series = {Haskell '12},
title = {Safe {Haskell}},
isbn = {978-1-4503-1574-6},
- url = {https://doi.org/10.1145/2364506.2364524},
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}},
series = {{ICFP} '14},
title = {Folding {Domain}-{Specific} {Languages}: {Deep} and {Shallow} {Embeddings} ({Functional} {Pearl})},
isbn = {978-1-4503-2873-9},
- url = {https://doi.org/10.1145/2628136.2628138},
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}},
series = {Haskell '05},
title = {{TypeCase}: {A} {Design} {Pattern} for {Type}-{Indexed} {Functions}},
isbn = {1-59593-071-X},
- url = {https://doi.org/10.1145/1088348.1088358},
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}},
series = {{POPL} '96},
title = {Putting {Type} {Annotations} to {Work}},
isbn = {0-89791-769-3},
- url = {https://doi.org/10.1145/237721.237729},
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}},
series = {{PEPM} '16},
title = {Everything {Old} is {New} {Again}: {Quoted} {Domain}-{Specific} {Languages}},
isbn = {978-1-4503-4097-7},
- url = {https://doi.org/10.1145/2847538.2847541},
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}},
series = {{DSL} '99},
title = {Domain {Specific} {Embedded} {Compilers}},
isbn = {1-58113-255-7},
- url = {https://doi.org/10.1145/331960.331977},
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}},
file = {Leijen and Meijer - 2000 - Domain Specific Embedded Compilers.pdf:/home/mrl/.local/share/zotero/storage/YHPF2VZ6/Leijen and Meijer - 2000 - Domain Specific Embedded Compilers.pdf:application/pdf},
}
-@incollection{koopman_simulation_2018,
- address = {Cham},
- title = {Simulation of a {Task}-{Based} {Embedded} {Domain} {Specific} {Language} for the {Internet} of {Things}},
- language = {en},
- booktitle = {Central {European} {Functional} {Programming} {School}: 7th {Summer} {School}, {CEFP} 2018, {Košice}, {Slovakia}, {January} 22–26, 2018, {Revised} {Selected} {Papers}},
- publisher = {Springer International Publishing},
- author = {Koopman, Pieter and Lubbers, Mart and Plasmeijer, Rinus},
- year = {2018},
- pages = {51},
-}
-
@techreport{plasmeijer_clean_2021,
address = {Nijmegen},
title = {Clean {Language} {Report} version 3.1},
address = {Hershey, PA, USA},
title = {Extensible {Languages}: {Blurring} the {Distinction} between {DSL} and {GPL}},
isbn = {978-1-4666-2092-6},
- url = {https://services.igi-global.com/resolvedoi/resolve.aspx?doi=10.4018/978-1-4666-2092-6.ch001},
abstract = {Out of a concern for focus and concision, domain-specific languages (DSLs) are usually very different from general purpose programming languages (GPLs), both at the syntactic and the semantic levels. One approach to DSL implementation is to write a full language infrastructure, including parser, interpreter, or even compiler. Another approach however, is to ground the DSL into an extensible GPL, giving you control over its own syntax and semantics. The DSL may then be designed merely as an extension to the original GPL, and its implementation may boil down to expressing only the differences with it. The task of DSL implementation is hence considerably eased. The purpose of this chapter is to provide a tour of the features that make a GPL extensible, and to demonstrate how, in this context, the distinction between DSL and GPL can blur, sometimes to the point of complete disappearance.},
booktitle = {Formal and {Practical} {Aspects} of {Domain}-{Specific} {Languages}: {Recent} {Developments}},
publisher = {IGI Global},
address = {Cham},
title = {Type-{Safe} {Functions} and {Tasks} in a {Shallow} {Embedded} {DSL} for {Microprocessors}},
isbn = {978-3-030-28346-9},
- url = {https://doi.org/10.1007/978-3-030-28346-9_8},
abstract = {The Internet of Things, IoT, brings us large amounts of connected computing devices that are equipped with dedicated sensors and actuators. These computing devices are typically driven by a cheap microprocessor system with a relatively slow processor and a very limited amount of memory. Due to the special input-output capabilities of IoT devices and their connections it is very attractive to execute (parts of) programs on these microcomputers.},
booktitle = {Central {European} {Functional} {Programming} {School}: 6th {Summer} {School}, {CEFP} 2015, {Budapest}, {Hungary}, {July} 6–10, 2015, {Revised} {Selected} {Papers}},
publisher = {Springer International Publishing},
series = {{ICFP} '02},
title = {Typing {Dynamic} {Typing}},
isbn = {1-58113-487-8},
- url = {https://doi.org/10.1145/581478.581494},
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}},
address = {Berlin, Heidelberg},
title = {On {Adding} {Pattern} {Matching} to {Haskell}-{Based} {Deeply} {Embedded} {Domain} {Specific} {Languages}},
isbn = {978-3-030-67437-3},
- url = {https://doi.org/10.1007/978-3-030-67438-0_2},
doi = {10.1007/978-3-030-67438-0_2},
abstract = {Capturing control flow is the Achilles heel of Haskell-based deeply embedded domain specific languages. Rather than use the builtin control flow mechanisms, artificial control flow combinators are used instead. However, capturing traditional control flow in a deeply embedded domain specific language would support the writing of programs in a natural style by allowing the programmer to use the constructs that are already builtin to the base language, such as pattern matching and recursion. In this paper, we expand the capabilities of Haskell-based deep embeddings with a compiler extension for reifying conditionals and pattern matching. With this new support, the subset of Haskell that we use for expressing deeply embedded domain specific languages can be cleaner, Haskell-idiomatic, and more declarative in nature.},
booktitle = {Practical {Aspects} of {Declarative} {Languages}: 23rd {International} {Symposium}, {PADL} 2021, {Copenhagen}, {Denmark}, {January} 18-19, 2021, {Proceedings}},
address = {Berlin, Heidelberg},
title = {Generic {Haskell}: {Practice} and {Theory}},
isbn = {978-3-540-45191-4},
- url = {https://doi.org/10.1007/978-3-540-45191-4_1},
abstract = {Generic Haskell is an extension of Haskell that supports the construction of generic programs. These lecture notes describe the basic constructs of Generic Haskell and highlight the underlying theory.},
booktitle = {Generic {Programming}: {Advanced} {Lectures}},
publisher = {Springer Berlin Heidelberg},
series = {{POPL} '93},
title = {Imperative {Functional} {Programming}},
isbn = {0-89791-560-7},
- url = {https://doi.org/10.1145/158511.158524},
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}},
series = {Haskell 2020},
title = {Staged {Sums} of {Products}},
isbn = {978-1-4503-8050-8},
- url = {https://doi.org/10.1145/3406088.3409021},
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}},
@article{xie_staging_2022,
title = {Staging with {Class}: {A} {Specification} for {Typed} {Template} {Haskell}},
volume = {6},
- url = {https://doi.org/10.1145/3498723},
doi = {10.1145/3498723},
abstract = {Multi-stage programming using typed code quotation is an established technique for writing optimizing code generators with strong type-safety guarantees. Unfortunately, quotation in Haskell interacts poorly with type classes, making it difficult to write robust multi-stage programs. We study this unsound interaction and propose a resolution, staged type class constraints, which we formalize in a source calculus λ⇒ that elaborates into an explicit core calculus F. We show type soundness of both calculi, establishing that well-typed, well-staged source programs always elaborate to well-typed, well-staged core programs, and prove beta and eta rules for code quotations. Our design allows programmers to incorporate type classes into multi-stage programs with confidence. Although motivated by Haskell, it is also suitable as a foundation for other languages that support both overloading and quotation.},
number = {POPL},
series = {{WGP} '14},
title = {True {Sums} of {Products}},
isbn = {978-1-4503-3042-8},
- url = {https://doi.org/10.1145/2633628.2633634},
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}},
@article{willis_staged_2020,
title = {Staged {Selective} {Parser} {Combinators}},
volume = {4},
- url = {https://doi.org/10.1145/3409002},
doi = {10.1145/3409002},
abstract = {Parser combinators are a middle ground between the fine control of hand-rolled parsers and the high-level almost grammar-like appearance of parsers created via parser generators. They also promote a cleaner, compositional design for parsers. Historically, however, they cannot match the performance of their counterparts. This paper describes how to compile parser combinators into parsers of hand-written quality. This is done by leveraging the static information present in the grammar by representing it as a tree. However, in order to exploit this information, it will be necessary to drop support for monadic computation since this generates dynamic structure. Selective functors can help recover lost functionality in the absence of monads, and the parser tree can be partially evaluated with staging. This is implemented in a library called Parsley.},
number = {ICFP},
series = {Haskell 2019},
title = {Multi-{Stage} {Programs} in {Context}},
isbn = {978-1-4503-6813-1},
- url = {https://doi.org/10.1145/3331545.3342597},
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}},
@article{pickering_specification_2021,
title = {A {Specification} for {Typed} {Template} {Haskell}},
volume = {abs/2112.03653},
- url = {https://arxiv.org/abs/2112.03653},
doi = {10.48550/arXiv.2112.03653},
journal = {CoRR},
author = {Pickering, Matthew and Löh, Andres and Wu, Nicolas},
@article{materzok_generating_2022,
title = {Generating {Circuits} with {Generators}},
volume = {6},
- url = {https://doi.org/10.1145/3549821},
doi = {10.1145/3549821},
abstract = {The most widely used languages and methods used for designing digital hardware fall into two rough categories. One of them, register transfer level (RTL), requires specifying each and every component in the designed circuit. This gives the designer full control, but burdens the designer with many trivial details. The other, the high-level synthesis (HLS) method, allows the designer to abstract the details of hardware away and focus on the problem being solved. This method however cannot be used for a class of hardware design problems because the circuit's clock is also abstracted away. We present YieldFSM, a hardware description language that uses the generator abstraction to represent clock-level timing in a digital circuit. It represents a middle ground between the RTL and HLS approaches: the abstraction level is higher than in RTL, but thanks to explicit information about clock-level timing, it can be used in applications where RTL is traditionally used. We also present the YieldFSM compiler, which uses methods developed by the functional programming community – including continuation-passsing style translation and defunctionalization – to translate YieldFSM programs to Mealy machines. It is implemented using Template Haskell and the Clash functional hardware description language. We show that this approach leads to short and conceptually simple hardware descriptions.},
number = {ICFP},
title = {Embedding {Non}-linear {Pattern} {Matching} with {Backtracking} for {Non}-free {Data} {Types} into {Haskell}},
volume = {40},
issn = {1882-7055},
- url = {https://doi.org/10.1007/s00354-022-00177-z},
doi = {10.1007/s00354-022-00177-z},
abstract = {Pattern matching is an important language construct for data abstraction. Many pattern-match extensions have been developed for extending the range of data types to which pattern matching is applicable. Among them, the pattern-match system proposed by Egi and Nishiwaki features practical pattern matching for non-free data types by providing a user-customizable non-linear pattern-match facility with backtracking. However, they implemented their proposal only in dynamically typed programming languages, and there were no proposals that allow programmers to benefit from both static type systems and expressive pattern matching. This paper proposes a method for implementing this pattern-match facility by meta-programming in Haskell. There are two technical challenges: (i) we need to design a set of typing rules for the pattern-match facility; (ii) we need to embed these typing rules in Haskell to make types of the pattern-match expressions inferable by the Haskell type system. We propose a set of typing rules and show that several GHC extensions, such as multi-parameter type classes, datatype promotion, GADTs, existential types, and view patterns, play essential roles for embedding these typing rules into Haskell. The implementation has already been distributed as a Haskell library miniEgison via Hackage.},
number = {2},
series = {Haskell 2022},
title = {Liquid {Proof} {Macros}},
isbn = {978-1-4503-9438-3},
- url = {https://doi.org/10.1145/3546189.3549921},
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}},
series = {Haskell 2022},
title = {Embedded {Pattern} {Matching}},
isbn = {978-1-4503-9438-3},
- url = {https://doi.org/10.1145/3546189.3549917},
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}},
title = {Internet of {Things}},
author = {Ashton, Kevin},
year = {1999},
+ note = {Presentation at Proctor \& Gamble},
}
@article{ashton_that_2009,
\usepackage{xcolor} % colors
\DeclareSIUnit\noop{\relax}
\DeclareSIUnit\celcius{{}^{\circ}\kern-\scriptspace\mathsf{C}}
-%\usepackage{atveryend} % \smaller command
\everymath{\it\/}
\DeclareMathSymbol{\shortminus}{\mathbin}{AMSa}{"39} %chktex 18
\newcommand{\dcolon}[0]{\mathbin{::}}
\fancyhead{}
\fancyfoot{}
\setlength{\unitlength}{18mm}
-\newcommand{\blob}{\rule[-.2\unitlength]{2\unitlength}{.5\unitlength}}
+\newcommand{\blob}{{\color{gray}\rule[-.2\unitlength]{2\unitlength}{.5\unitlength}}}
\fancyhead[RE]{\rightmark}
\fancyhead[LO]{\leftmark}
\newcommand{\frontmatterfancy}[0]{
\usepackage{appendix} % subappendices, appendices per chapter
% Bibliography
-\usepackage{bibentry} % Cite bib entry completely
-\nobibliography*
\usepackage{natbib} % Cite bib entry completely
\setlength{\bibsep}{0.0pt}
\def\bibfont{\small}
%\bibliographystyle{alpha}
\bibliographystyle{abbrvnat}
\apptocmd{\thebibliography}{\raggedright}{}{}
+\usepackage{bibentry} % Cite bib entry completely
+\nobibliography*
% Graphics
\usepackage{graphicx} % Images
% Hyperlinks and metadata
\usepackage[pdflang={en-GB},pagebackref]{hyperref} % hyperlinks
+\usepackage{xr} % hyperlinks
\renewcommand*{\backref}[1]{}
\renewcommand*{\backrefalt}[4]{[{%
\ifcase #1 not cited.\or p.~#2.\else pp. #2.\fi%chktex 1
% Custom commands
\newcommand{\GHCmod}[1]{\texttt{#1}}
\newcommand{\requiresGHCmod}[2][]{\footnote{Requires \GHCmod{#2} to be enabled. #1}}
-\newcommand{\etc}{{\fontfamily{cmr}\selectfont{\itshape\/\&c}}}
+%\newcommand{\etc}{{\fontfamily{cmr}\selectfont{\itshape\/\&c}}}
+\newcommand{\etc}{{\fontfamily{cmr}\selectfont{\itshape\/\&\kern-0.2em c}}}
\newcommand{\rdmentry}[6]{#1: #2 (#3): #4. #5.\ \href{https://doi.org/#6}{#6}}
\newcommand{\mlubbers}{Lubbers, M.\ (Radboud University)}
\newcommand{\pkoopman}{Koopman, dr.\ P.\ (Radboud University)}
+
+@inproceedings{lubbers_interpreting_2019,
+ address = {New York, NY, USA},
+ series = {{IFL} '19},
+ title = {Interpreting {Task} {Oriented} {Programs} on {Tiny} {Computers}},
+ isbn = {978-1-4503-7562-7},
+ 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},
+ author = {Lubbers, Mart and Koopman, Pieter and Plasmeijer, Rinus},
+ editor = {Stutterheim, Jurriën and Chin, Wei Ngan},
+ year = {2019},
+ note = {event-place: Singapore, Singapore},
+ keywords = {clean, distributed applications, functional programming, internet of things, task oriented programming},
+ file = {Lubbers et al. - 2019 - Interpreting Task Oriented Programs on Tiny Comput.pdf:/home/mrl/.local/share/zotero/storage/ATYSJXJ3/Lubbers et al. - 2019 - Interpreting Task Oriented Programs on Tiny Comput.pdf:application/pdf},
+}
+
+@incollection{lubbers_writing_2019,
+ address = {Cham},
+ title = {Writing {Internet} of {Things} applications with {Task} {Oriented} {Programming}},
+ abstract = {The Internet of Things (IOT) is growing fast. In 2018, there was approximately one connected device per person on earth and the number has been growing ever since. The devices interact with the environment via different modalities at the same time using sensors and actuators making the programs parallel. Yet, writing this type of programs is difficult because the devices have little computation power and memory, the platforms are heterogeneous and the languages are low level. Task Oriented Programming (TOP) is a novel declarative programming language paradigm that is used to express coordination of work, collaboration of users and systems, the distribution of shared data and the human computer interaction. The mTask language is a specialized, yet full-fledged, multi-backend TOP language for IOT devices. With the bytecode interpretation backend and the integration with iTasks, tasks can be executed on the device dynamically. This means that —according to the current state of affairs— tasks can be tailor-made at run time, compiled to device-agnostic bytecode and shipped to the device for interpretation. Tasks sent to the device are fully integrated in iTasks to allow every form of interaction with the tasks such as observation of the task value and interaction with Shared Data Sources (SDSs). The application is —server and devices— are programmed in a single language, albeit using two embedded Domain Specific Languages (EDSLs).},
+ language = {en},
+ booktitle = {Central {European} {Functional} {Programming} {School}: 8th {Summer} {School}, {CEFP} 2019, {Budapest}, {Hungary}, {July} 17–21, 2019, {Revised} {Selected} {Papers}},
+ publisher = {Springer International Publishing},
+ author = {Lubbers, Mart and Koopman, Pieter and Plasmeijer, Rinus},
+ year = {2019},
+ note = {in-press},
+ pages = {51},
+ file = {Lubbers - Writing Internet of Things applications with Task .pdf:/home/mrl/.local/share/zotero/storage/ILZIBYW5/Lubbers - Writing Internet of Things applications with Task .pdf:application/pdf},
+}
+
+@inproceedings{lubbers_tiered_2020,
+ address = {Malmö},
+ series = {{IoT} '20},
+ title = {Tiered versus {Tierless} {IoT} {Stacks}: {Comparing} {Smart} {Campus} {Software} {Architectures}},
+ isbn = {978-1-4503-8758-3},
+ 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},
+ author = {Lubbers, Mart and Koopman, Pieter and Ramsingh, Adrian and Singer, Jeremy and Trinder, Phil},
+ year = {2020},
+ note = {event-place: Malmö, Sweden},
+ keywords = {internet of things, domain specific languages, network reliability, software architectures},
+ file = {Lubbers et al. - 2020 - Tiered versus Tierless IoT Stacks Comparing Smart.pdf:/home/mrl/.local/share/zotero/storage/YY3MJRZ6/Lubbers et al. - 2020 - Tiered versus Tierless IoT Stacks Comparing Smart.pdf:application/pdf},
+}
+
+@inproceedings{koopman_task-based_2018,
+ address = {Vienna, Austria},
+ title = {A {Task}-{Based} {DSL} for {Microcomputers}},
+ copyright = {All rights reserved},
+ isbn = {978-1-4503-6355-6},
+ doi = {10.1145/3183895.3183902},
+ abstract = {The Internet of Things, IoT, makes small connected computing devices almost omnipresent. These devices have typically very limited computing power and severe memory restrictions to make them cheap and power efficient. These devices can interact with the environment via special sensors and actuators. Since each device controls several peripherals running interleaved, the control software is quite complicated and hard to maintain. Task Oriented Programming, TOP, offers lightweight communicating threads that can inspect each other’s intermediate results. This makes it well suited for the IoT. In this paper presents a functional task-based domain specific language for these IoT devices. We show that it yields concise control programs. By restricting the datatypes and using strict evaluation these programs fit within the restrictions of microcontrollers.},
+ language = {en},
+ urldate = {2019-01-14},
+ booktitle = {Proceedings of the {Real} {World} {Domain} {Specific} {Languages} {Workshop} 2018 on - {RWDSL2018}},
+ publisher = {ACM Press},
+ author = {Koopman, Pieter and Lubbers, Mart and Plasmeijer, Rinus},
+ year = {2018},
+ pages = {1--11},
+ file = {a4-Koopman.pdf:/home/mrl/.local/share/zotero/storage/TXZD529C/a4-Koopman.pdf:application/pdf;Koopman et al. - 2018 - A Task-Based DSL for Microcomputers.pdf:/home/mrl/.local/share/zotero/storage/9ETMTMX2/Koopman et al. - 2018 - A Task-Based DSL for Microcomputers.pdf:application/pdf},
+}
+
@inproceedings{lubbers_multitasking_2019,
address = {Opatija, Croatia},
title = {Multitasking on {Microcontrollers} using {Task} {Oriented} {Programming}},
month = may,
year = {2019},
pages = {1587--1592},
- file = {08756711.pdf:/home/mrl/.local/share/zotero/storage/4S44JZPK/08756711.pdf:application/pdf;mipro_2019_proceedings.pdf:/home/mrl/.local/share/zotero/storage/5FFJLMTG/mipro_2019_proceedings.pdf:application/pdf;03_4cows_5338.pdf:/home/mrl/.local/share/zotero/storage/3QJTF5HT/03_4cows_5338.pdf:application/pdf}
+ file = {03_4cows_5338.pdf:/home/mrl/.local/share/zotero/storage/3QJTF5HT/03_4cows_5338.pdf:application/pdf;08756711.pdf:/home/mrl/.local/share/zotero/storage/4S44JZPK/08756711.pdf:application/pdf;mipro_2019_proceedings.pdf:/home/mrl/.local/share/zotero/storage/5FFJLMTG/mipro_2019_proceedings.pdf:application/pdf},
+}
+
+@phdthesis{lubbers_adaptable_2015,
+ address = {Nijmegen},
+ type = {Bachelor's {Thesis}},
+ title = {Adaptable crawler specification generation system for leisure activity {RSS} feeds},
+ copyright = {All rights reserved},
+ url = {http://theses.ubn.ru.nl/handle/123456789/220},
+ urldate = {2017-04-12},
+ school = {Radboud University},
+ author = {Lubbers, Mart},
+ year = {2015},
+ file = {Adaptable crawler specification generation system for leisure activity RSS feeds - Lubbers,M._BA_Thesis_2015.pdf:/home/mrl/.local/share/zotero/storage/7SDHJ3KD/Lubbers,M._BA_Thesis_2015.pdf:application/pdf},
}
@inproceedings{lubbers_task_2018,
author = {Lubbers, Mart and Koopman, Pieter and Plasmeijer, Rinus},
year = {2018},
pages = {83--94},
- file = {Lubbers et al. - 2018 - Task Oriented Programming and the Internet of Thin.pdf:/home/mrl/.local/share/zotero/storage/3E5KLI5V/Lubbers et al. - 2018 - Task Oriented Programming and the Internet of Thin.pdf:application/pdf}
+ file = {Lubbers et al. - 2018 - Task Oriented Programming and the Internet of Thin.pdf:/home/mrl/.local/share/zotero/storage/3E5KLI5V/Lubbers et al. - 2018 - Task Oriented Programming and the Internet of Thin.pdf:application/pdf},
}
@mastersthesis{lubbers_task_2017,
school = {Radboud University},
author = {Lubbers, Mart},
year = {2017},
- file = {thesis.pdf:/home/mrl/.local/share/zotero/storage/M49MWHPX/thesis.pdf:application/pdf}
+ file = {thesis.pdf:/home/mrl/.local/share/zotero/storage/M49MWHPX/thesis.pdf:application/pdf},
}
-@inproceedings{lubbers_interpreting_2019,
- address = {Singapore},
- title = {Interpreting {Task} {Oriented} {Programs} on {Tiny} {Computers}},
- copyright = {All rights reserved},
- language = {en},
- booktitle = {Proceedings of the 31th {Symposium} on the {Implementation} and {Application} of {Functional} {Programming} {Languages}},
- publisher = {ACM},
- author = {Lubbers, Mart and Koopman, Pieter and Plasmeijer, Rinus},
- year = {2019},
- pages = {12},
- file = {pre-conference-proceedings.pdf:/home/mrl/.local/share/zotero/storage/E4R53TGR/pre-conference-proceedings.pdf:application/pdf;Lubbers et al. - 2020 - Interpreting Task Oriented Programs on Tiny Comput.pdf:/home/mrl/.local/share/zotero/storage/8QXYMUIX/Lubbers et al. - 2020 - Interpreting Task Oriented Programs on Tiny Comput.pdf:application/pdf}
+@article{schuerman_praatalign:_2015,
+ title = {Praatalign: {Phonetic} {Alignment} {Made} {Easier} {For} {Psycholinguistic} {Data} {Processing}},
+ journal = {Architectures and Mechanisms for Language Processing},
+ author = {Schuerman, Will and Torreira, Francisco and Lubbers, Mart},
+ year = {2015},
+ pages = {92},
+ file = {amlap2015.pdf:/home/mrl/.local/share/zotero/storage/H9WTW9TM/amlap2015.pdf:application/pdf;Will_Schuerman_AMLAP2015_Draft2.pdf:/home/mrl/.local/share/zotero/storage/BFBDDVIQ/Will_Schuerman_AMLAP2015_Draft2.pdf:application/pdf},
}
-@inproceedings{koopman_task-based_2018,
- address = {Vienna, Austria},
- title = {A {Task}-{Based} {DSL} for {Microcomputers}},
- copyright = {All rights reserved},
- isbn = {978-1-4503-6355-6},
- doi = {10.1145/3183895.3183902},
- abstract = {The Internet of Things, IoT, makes small connected computing devices almost omnipresent. These devices have typically very limited computing power and severe memory restrictions to make them cheap and power efficient. These devices can interact with the environment via special sensors and actuators. Since each device controls several peripherals running interleaved, the control software is quite complicated and hard to maintain. Task Oriented Programming, TOP, offers lightweight communicating threads that can inspect each other’s intermediate results. This makes it well suited for the IoT. In this paper presents a functional task-based domain specific language for these IoT devices. We show that it yields concise control programs. By restricting the datatypes and using strict evaluation these programs fit within the restrictions of microcontrollers.},
+@incollection{koopman_simulation_2018,
+ address = {Cham},
+ title = {Simulation of a {Task}-{Based} {Embedded} {Domain} {Specific} {Language} for the {Internet} of {Things}},
language = {en},
- urldate = {2019-01-14},
- booktitle = {Proceedings of the {Real} {World} {Domain} {Specific} {Languages} {Workshop} 2018 on - {RWDSL2018}},
- publisher = {ACM Press},
+ booktitle = {Central {European} {Functional} {Programming} {School}: 7th {Summer} {School}, {CEFP} 2018, {Košice}, {Slovakia}, {January} 22–26, 2018, {Revised} {Selected} {Papers}},
+ publisher = {Springer International Publishing},
author = {Koopman, Pieter and Lubbers, Mart and Plasmeijer, Rinus},
year = {2018},
- pages = {1--11},
- file = {a4-Koopman.pdf:/home/mrl/.local/share/zotero/storage/TXZD529C/a4-Koopman.pdf:application/pdf;Koopman et al. - 2018 - A Task-Based DSL for Microcomputers.pdf:/home/mrl/.local/share/zotero/storage/9ETMTMX2/Koopman et al. - 2018 - A Task-Based DSL for Microcomputers.pdf:application/pdf}
+ note = {in-press},
+ pages = {51},
}
-@inproceedings{lubbers_tiered_2020,
- address = {Malmö},
- series = {{IoT} '20},
- title = {Tiered versus {Tierless} {IoT} {Stacks}: {Comparing} {Smart} {Campus} {Software} {Architectures}},
- isbn = {978-1-4503-8758-3},
- 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}},
+@misc{koopman_sustrainable_2022,
+ title = {{SusTrainable}: {Promoting} {Sustainability} as a {Fundamental} {Driver} in {Software} {Development} {Training} and {Education}. {Teacher} {Training}, {November} 1-5, {Nijmegen}, {The} {Netherlands}. {Revised} lecture notes},
+ copyright = {Creative Commons Attribution Non Commercial No Derivatives 4.0 International},
+ publisher = {arXiv},
+ author = {Koopman, Pieter and Lubbers, Mart and Fernandes, João Paulo},
+ year = {2022},
+ doi = {10.48550/ARXIV.2204.13993},
+ keywords = {Computers and Society (cs.CY), FOS: Computer and information sciences, Software Engineering (cs.SE)},
+ file = {Koopman et al. - 2022 - SusTrainable Promoting Sustainability as a Fundam.pdf:/home/mrl/.local/share/zotero/storage/5F9SRJQI/Koopman et al. - 2022 - SusTrainable Promoting Sustainability as a Fundam.pdf:application/pdf},
+}
+
+@inproceedings{lubbers_deep_2022,
+ address = {Berlin, Heidelberg},
+ title = {Deep {Embedding} with {Class}},
+ booktitle = {Revised {Selected} {Papers} from the 23rd {International} {Symposium} on {Trends} in {Functional} {Programming}, {TFP} 2022, {Online}, 17-18 {March} 2022},
+ publisher = {Springer Berlin Heidelberg},
+ author = {Lubbers, Mart},
+ year = {2022},
+ note = {in-press},
+ pages = {20},
+}
+
+@inproceedings{lubbers_first-class_2022,
+ address = {New York, NY, USA},
+ 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},
+ author = {Lubbers, Mart and Koopman, Pieter and Plasmeijer, Rinus},
+ year = {2022},
+ note = {event-place: Kopenhagen, Denmark. under-review},
+ keywords = {clean, distributed applications, functional programming, internet of things, task oriented programming},
+}
+
+@inproceedings{crooijmans_reducing_2022,
+ address = {Berlin, Heidelberg},
+ title = {Reducing the {Power} {Consumption} of {IoT} with {Task}-{Oriented} {Programming}},
+ booktitle = {Revised {Selected} {Papers} from the 23rd {International} {Symposium} on {Trends} in {Functional} {Programming}, {TFP} 2022, {Online}, 17-18 {March} 2022},
+ publisher = {Springer Berlin Heidelberg},
+ author = {Crooijmans, Sjoerd and Lubbers, Mart and Koopman, Pieter},
+ year = {2022},
+ note = {in-press},
+ pages = {20},
+}
+
+@article{lubbers_could_2022,
+ title = {Could {Tierless} {Languages} {Reduce} {IoT} {Development} {Grief}?},
+ volume = {3},
+ number = {5},
+ journal = {ACM Trans. Internet Things},
author = {Lubbers, Mart and Koopman, Pieter and Ramsingh, Adrian and Singer, Jeremy and Trinder, Phil},
- year = {2020},
- note = {event-place: Malmö, Sweden},
- keywords = {domain specific languages, internet of things, network reliability, software architectures},
- file = {Lubbers et al. - 2020 - Tiered versus Tierless IoT Stacks Comparing Smart.pdf:/home/mrl/.local/share/zotero/storage/YY3MJRZ6/Lubbers et al. - 2020 - Tiered versus Tierless IoT Stacks Comparing Smart.pdf:application/pdf}
+ month = sep,
+ year = {2022},
+ note = {Place: New York, NY, USA
+Publisher: Association for Computing Machinery
+under-review},
+ keywords = {access control, internet-of-things, policy language, privilege escalation, Smart home system},
}
--- /dev/null
+\ifSubfilesClassLoaded{
+ \pagenumbering{arabic}
+ \externaldocument{thesis}
+}{}
\overfullrule=1mm
% Just for the todonotes, can go when it's finished
-\usepackage[disable]{todonotes}
+\usepackage{todonotes}
\setuptodonotes{
backgroundcolor=white,
linecolor=black,
- size=scriptsize,
+ size=tiny,
}
%\newcommand{\todo}[2][1]{1}
%\newcommand{\listoftodos}{}
\section{Types}
To leverage the type checker of the host language, types in the \gls{MTASK} language are expressed as types in the host language, to make the language type safe.
However, not all types in the host language are suitable for microprocessors that may only have \qty{2}{\kibi\byte} of \gls{RAM} so class constraints are therefore added to the \gls{DSL} functions.
-The most used class constraint is the \cleaninline{type} class collection containing functions for serialization, printing, \gls{ITASK} constraints etc.
+The most used class constraint is the \cleaninline{type} class collection containing functions for serialization, printing, \gls{ITASK} constraints \etc.
Many of these functions can be derived using generic programming.
An even stronger restriction on types is defined for types that have a stack representation.
This \cleaninline{basicType} class has instances for many \gls{CLEAN} basic types such as \cleaninline{Int}, \cleaninline{Real} and \cleaninline{Bool}.
In a tierless language the developer writes the application as a single program. The code for different tiers is simultaneously checked by the compiler, and compiled to the required component languages. For example, Links compiles to HTML and JavaScript for the web client and to SQL on the server to interact with the database system. Tierless languages for \gls{IOT} stacks are more recent and less common, examples include
Potato~\citep{troyer_building_2018} and \gls{CLEAN} with \gls{ITASK}\slash\gls{MTASK}~\citep{lubbers_interpreting_2019}.
-\Gls{IOT} sensor nodes may be microprocessors with very limited compute resources, or supersensors: resource-rich single board computers like a Raspberry Pi. A tierless language may target either class of sensor node, and microcontrollers are the more demanding target due to the limited resources, e.g.\ small memory, executing on bare metal etc.
+\Gls{IOT} sensor nodes may be microprocessors with very limited compute resources, or supersensors: resource-rich single board computers like a Raspberry Pi. A tierless language may target either class of sensor node, and microcontrollers are the more demanding target due to the limited resources, e.g.\ small memory, executing on bare metal \etc.
Potentially a tierless language both reduces the development effort and improves correctness as correct interoperation and communication is automatically generated by the compiler. A tierless language may, however, introduce other problems. How expressive is the language? That is, can it readily express the required functionality? How maintainable is the software? Is the generated code efficient in terms of time, space, and power?
There are also standard combinators for common patterns.
Tasks can exchange information via \glspl{SDS}~\citep{ParametricLenses}.
All tasks involved can atomically observe and change the value of a typed \gls{SDS}, allowing more flexible communication than with task combinators.
-\glspl{SDS} offer a general abstraction of data shared by different tasks, analogous to variables, persistent values, files, databases and peripherals like sensors. Combinators compose \glspl{SDS} into a larger \gls{SDS}, and
+\Glspl{SDS} offer a general abstraction of data shared by different tasks, analogous to variables, persistent values, files, databases and peripherals like sensors. Combinators compose \glspl{SDS} into a larger \gls{SDS}, and
parametric lenses define a specific view on an \gls{SDS}.
-
-
\subsection{The \texorpdfstring{\gls{ITASK}}{iTask} \texorpdfstring{\gls{EDSL}}{eDSL}}%
\label{sec_t4t:itasks}
-
-
The \gls{ITASK} \gls{EDSL} is designed for constructing multi-user distributed applications, including web~\citep{TOP-ICFP07} or \gls{IOT} applications.
Here we present \gls{ITASK} by example, and the first is a complete program to repeatedly read the room temperature from a digital humidity and temperature (DHT) sensor attached to the machine and display it on a web page (\cref{lst_t4t:itaskTemp}).
The first line is the module name, the third imports the \cleaninline{iTask} module, and the main function (\cref{lst_t4t:itaskTemp:systemfro,lst_t4t:itaskTemp:systemto}) launches \cleaninline{readTempTask} and the \gls{ITASK} system to generate the web interface in \cref{fig_t4t:itaskTempSimple}.
\label{sec_t4t:mtaskIOT}
A tierless \gls{CLEAN} \gls{IOT} system with microprocessor sensor nodes integrates a set of \gls{ITASK} tasks that specify the application and presentation layers with a set of \gls{MTASK}s that specify the perception and network layers.
-We illustrate with \gls{CWTS}: a simple room temperature sensor with a web display. \gls{CWTS} is equivalent to the \gls{ITASK} \gls{CRTS} (\cref{lst_t4t:itaskTempFull}), except that the sensor node is a Wemos microprocessor.
+We illustrate with \gls{CWTS}: a simple room temperature sensor with a web display. \gls{CWTS} is equivalent to the \gls{ITASK} \gls{CRTS} (\cref{lst_t4t:itaskTempFull}), except that the sensor node is a \gls{WEMOS} microprocessor.
\Cref{lst_t4t:mtaskTemp} shows the complete program, and the key function is \cleaninline{devTask} with a top-level \cleaninline{Main} type (\cref{lst_t4t:mtaskTemp:devTask}). In \gls{MTASK} functions, shares, and devices can only be defined at this top level.
The program uses the same shares \cleaninline{tempSDS} and~\cleaninline{latestTemp} as \gls{CRTS}, and for completeness we repeat those definitions.
\section{\texorpdfstring{\gls{UOG}}{UoG} smart campus case study}%
\label{sec_t4t:Case}
The basis for our comparison between tiered and tierless technologies are four \gls{IOT} systems that all conform to the \gls{UOG} smart campus specifications (\cref{sec_t4t:OperationalComparison}). There is a small (12 room) deployment of the conventional \gls{PYTHON}-based \gls{PRS} stack that uses Raspberry Pi supersensors, and its direct comparator is the tierless \gls{CRS} implementation: also deployed on Raspberry Pis.
-To represent the more common microprocessor sensor nodes we select ESP8266X powered Wemos D1 Mini microcontrollers. To evaluate tierless technologies on microcontrollers we compare the conventional \gls{PYTHON}\slash\gls{MICROPYTHON} \gls{PWS} stack with the tierless \gls{CWS} implementation.
+To represent the more common microprocessor sensor nodes we select ESP8266X powered \gls{WEMOS} D1 Mini microcontrollers. To evaluate tierless technologies on microcontrollers we compare the conventional \gls{PYTHON}\slash\gls{MICROPYTHON} \gls{PWS} stack with the tierless \gls{CWS} implementation.
%The four systems under comparison are different in architecture ---tiered or tierless--- and type of sensor node hardware ---regular or embedded--- but they share many properties as well.
-%The embedded sensor nodes are all implemented on the ESP8266X powered Wemos D1 Mini microprocessor.
-A similar range of commodity sensors is connected to both the Raspberry Pi and Wemos sensor nodes using various low-level communication protocols such as \gls{GPIO}, \gls{I2C}, \gls{SPI} and \gls{ONEWIRE}. The sensors are as follows: Temperature \& Humidity: LOLIN SHT30; Light: LOLIN BH1750; Motion: LOLIN \gls{PIR}; Sound: SparkFun SEN-12642; \gls{ECO2}: SparkFun CCS811.
+%The embedded sensor nodes are all implemented on the ESP8266X powered \gls{WEMOS} D1 Mini microprocessor.
+A similar range of commodity sensors is connected to both the Raspberry Pi and \gls{WEMOS} sensor nodes using various low-level communication protocols such as \gls{GPIO}, \gls{I2C}, \gls{SPI} and \gls{ONEWIRE}. The sensors are as follows: Temperature \& Humidity: LOLIN SHT30; Light: LOLIN BH1750; Motion: LOLIN \gls{PIR}; Sound: SparkFun SEN-12642; \gls{ECO2}: SparkFun CCS811.
-\Cref{fig_t4t:wemos_prss} shows both a prototype Wemos-based sensor node and sensors and a Raspberry Pi supersensor. Three different development teams developed the four implementations: \gls{CWS} and \gls{CRS} were engineered by a single developer.
+\Cref{fig_t4t:wemos_prss} shows both a prototype \gls{WEMOS}-based sensor node and sensors and a Raspberry Pi supersensor. Three different development teams developed the four implementations: \gls{CWS} and \gls{CRS} were engineered by a single developer.
\begin{figure}[ht]
\centering
\begin{subfigure}[t]{.49\textwidth}
\centering
\includegraphics[width=.9\textwidth]{wemos}
- \caption{A Wemos used in \gls{PWS} and \gls{CWS}}.%
+ \caption{A \gls{WEMOS} used in \gls{PWS} and \gls{CWS}}.%
\end{subfigure}%
\begin{subfigure}[t]{.49\textwidth}
\centering
\Gls{CRS}'s sensor nodes are Raspberry Pi 4s, and execute \gls{CLEAN}\slash\gls{ITASK} programs.
Communication from the sensor node to the server is implicit and happens via \glspl{SDS} over \gls{TCP} using platform independent execution graph serialisation~\citep{oortgiese_distributed_2017}.
-\Gls{CWS}'s sensor nodes are Wemos microprocessors running \gls{MTASK} tasks. Communication and serialisation is, by design, very similar to \gls{ITASK}, i.e.\ via \glspl{SDS} over either a serial port connection, raw \gls{TCP}, or \gls{MQTT} over \gls{TCP}.
+\Gls{CWS}'s sensor nodes are \gls{WEMOS} microprocessors running \gls{MTASK} tasks. Communication and serialisation is, by design, very similar to \gls{ITASK}, i.e.\ via \glspl{SDS} over either a serial port connection, raw \gls{TCP}, or \gls{MQTT} over \gls{TCP}.
\begin{figure}[ht]
\centering
\end{tabular}
\end{table}
-\Cref{tbl_t4t:mem} shows the maximum memory residency after garbage collection of the sensor node for all four smart campus implementations. The smart campus sensor node programs executing on the Wemos microprocessors have low maximum residencies: \qty{20270}{\byte} for \gls{PWS} and \qty{880}{\byte} for \gls{CWS}. In \gls{CWS} the \gls{MTASK} system generates very high level \gls{TOP} byte code that is interpreted by the \gls{MTASK} virtual machine and uses a small and predictable amount of heap memory.
+\Cref{tbl_t4t:mem} shows the maximum memory residency after garbage collection of the sensor node for all four smart campus implementations. The smart campus sensor node programs executing on the \gls{WEMOS} microprocessors have low maximum residencies: \qty{20270}{\byte} for \gls{PWS} and \qty{880}{\byte} for \gls{CWS}. In \gls{CWS} the \gls{MTASK} system generates very high level \gls{TOP} byte code that is interpreted by the \gls{MTASK} virtual machine and uses a small and predictable amount of heap memory.
In \gls{PWS}, the hand-written \gls{MICROPYTHON} is compiled to byte code for execution on the virtual machine. Low residency is achieved with a fixed size heap and efficient memory management. For example both \gls{MICROPYTHON} and \gls{MTASK} use fixed size allocation units and mark\&sweep garbage collection to minimise memory usage at the cost of some execution time~\citep{plamauer2017evaluation}.
The smart campus sensor node programs executing on the Raspberry Pis have far higher maximum residencies than those executing on the microprocessors: \qty{3.5}{\mebi\byte} for \gls{PRS} and \qty{2.7}{\mebi\byte} for \gls{CRS}. In \gls{CRS} the sensor node code is a set of \gls{ITASK} executing on a full-fledged \gls{ITASK} server running in distributed child mode and this consumes far more memory.
\paragraph{Power} Sensor nodes and sensors are designed to have low power demands, and this is particularly important if they are operating on batteries. The grey literature consensus is that with all sensors enabled a sensor node should typically have sub-\qty{1}{\watt} peak power draw.
%\pwtcomment{Mart can you provide some evidence? A citation?}.
-%\mlcomment{There only seems to be anecdotal evidence of this. See: \url{https://www.element14.com/community/people/neilk/blog/2019/02/14/investigating-the-power-consumption-of-a-wemos-d1-mini-esp8266}}
+%\mlcomment{There only seems to be anecdotal evidence of this. See: \url{https://www.element14.com/community/people/neilk/blog/2019/02/14/investigating-the-power-consumption-of-a-\gls{WEMOS}-d1-mini-esp8266}}
%\pkcomment{We can state that our own measurements are consistent the experience of others.}
-The Wemos sensor nodes used in \gls{CWS} and \gls{PWS} have the low power consumption of a typical embedded device: with all sensors enabled, they consume around \qty{0.2}{\watt}.
+The \gls{WEMOS} sensor nodes used in \gls{CWS} and \gls{PWS} have the low power consumption of a typical embedded device: with all sensors enabled, they consume around \qty{0.2}{\watt}.
The Raspberry Pi supersensor node used in \gls{CRS} and \gls{PRS} use more power as they have a general purpose ARM processor and run mainstream Linux. With all sensors enabled, they consume \qtyrange{1}{2}{\watt}, depending on ambient load. So a microprocessor sensor node consumes an order of magnitude less power than a supersensor node.
Of course \gls{SLOC} must be used carefully as it is easily influenced by programming style, language paradigm, and counting method~\citep{alpernaswonderful}. Here we are counting code to compare development effort, use the same idiomatic programming style in each component, and only count lines of code, omitting comments and blank lines.
-\Cref{table_t4t:multi} enumerates the \gls{SLOC} required to implement the \gls{UOG} smart campus functionalities in \gls{PWS}, \gls{PRS}, \gls{CWS} and \gls{CRS}. Both \gls{PYTHON} and \gls{CLEAN} implementations use the same server and communication code for Raspberry Pi and for Wemos sensor nodes (rows 5--7 of the table).
+\Cref{table_t4t:multi} enumerates the \gls{SLOC} required to implement the \gls{UOG} smart campus functionalities in \gls{PWS}, \gls{PRS}, \gls{CWS} and \gls{CRS}. Both \gls{PYTHON} and \gls{CLEAN} implementations use the same server and communication code for Raspberry Pi and for \gls{WEMOS} sensor nodes (rows 5--7 of the table).
The Sensor Interface (SI) refers to code facilitating the communication between the peripherals and the sensor node software. % formerly hardware interface
Sensor Node (SN) code contains all other code on the sensor node that does not belong to any another category, such as control flow. % formerly device output
%Server communication denotes code that provides the high level communication between the sensor node and the server.
The architecture consists of a server and a single sensor node (\cref{fig_t4t:cwtsDiagram}).
The sensor node measures and reports the temperature every ten seconds to the server while the server displays the latest temperature via a web interface to the user.
-\Cref{table_t4t:temp} compares the \gls{SLOC} required for the \gls{MICROPYTHON} and \gls{CLEAN}\slash\gls{ITASK}/\gls{MTASK} Wemos temperature sensors: \gls{PWTS} and \gls{CWTS} respectively. The code sizes here should not be used to compare the programming models as implementing such a small application as a conventional \gls{IOT} stack requires a significant amount of configuration and other machinery that would be reused in a larger application. Hence, the ratio between total \gls{PWTS} and \gls{CWTS} code sizes (298:15) is far greater than for realistic applications like \gls{PWS} and \gls{CWS} (471:166).
+\Cref{table_t4t:temp} compares the \gls{SLOC} required for the \gls{MICROPYTHON} and \gls{CLEAN}\slash\gls{ITASK}/\gls{MTASK} \gls{WEMOS} temperature sensors: \gls{PWTS} and \gls{CWTS} respectively. The code sizes here should not be used to compare the programming models as implementing such a small application as a conventional \gls{IOT} stack requires a significant amount of configuration and other machinery that would be reused in a larger application. Hence, the ratio between total \gls{PWTS} and \gls{CWTS} code sizes (298:15) is far greater than for realistic applications like \gls{PWS} and \gls{CWS} (471:166).
\begin{table}
\centering
\Cref{table_t4t:languagecomparison} summarises the differences between the \gls{CLEAN} \gls{IOT} \gls{EDSL} and their host language.
The restrictions imposed by a resource-constrained execution environment on the tierless \gls{IOT} language are relatively minor. Moreover the \gls{MTASK} programming abstraction is broadly compatible with \gls{ITASK}. As a simple example compare the \gls{ITASK} and \gls{MTASK} temperature sensors in \cref{lst_t4t:itaskTempFull,lst_t4t:mtaskTemp}. As a more realistic example, the \gls{MTASK} based \gls{CWS} smart campus implementation is similar to the \gls{ITASK} based \gls{CRS}, and requires less than 10\% additional code: 166 \gls{SLOC} compared with 155 \gls{SLOC} (\cref{table_t4t:multi}).
-Even with these restrictions, \gls{MTASK} programming is at a far higher level of abstraction than almost all bare metal languages, e.g.\ BIT, PICBIT, PICOBIT and Microscheme. That is \gls{MTASK} provides a set of higher order task combinators, shared distributed data stores, etc. (\cref{sec_t4t:mtasks}). Moreover, it seems that common sensor node programs are readily expressed using \gls{MTASK}. In addition to the \gls{CWTS} and \gls{CWS} systems outlined here, other case studies include Arduino examples as well as some bigger tasks~\citep{koopman_task-based_2018,lubbers_writing_2019,LubbersMIPRO}. We conclude that the programming of sensor tasks is well-supported by both \glspl{DSL}.
+Even with these restrictions, \gls{MTASK} programming is at a far higher level of abstraction than almost all bare metal languages, e.g.\ BIT, PICBIT, PICOBIT and Microscheme. That is \gls{MTASK} provides a set of higher order task combinators, shared distributed data stores, \etc. (\cref{sec_t4t:mtasks}). Moreover, it seems that common sensor node programs are readily expressed using \gls{MTASK}. In addition to the \gls{CWTS} and \gls{CWS} systems outlined here, other case studies include Arduino examples as well as some bigger tasks~\citep{koopman_task-based_2018,lubbers_writing_2019,LubbersMIPRO}. We conclude that the programming of sensor tasks is well-supported by both \glspl{DSL}.
\section{Conclusion}%
\label{sec_t4t:Conclusion}
as it is in the tiered \gls{PYTHON} implementations (\cref{fig_t4t:multipercentage}). This suggests that the code for resource-constrained and resource-rich sensor nodes can be broadly similar in tierless technologies, as it is in many tiered technologies (\cref{sec_t4t:resourcerich}).
\end{enumerate*}
-We present \emph{the first comparison of two tierless \gls{IOT} languages: one designed for resource-constrained sensor nodes (\gls{CLEAN} with \gls{ITASK} and \gls{MTASK}), and the other for resource-rich sensor nodes (\gls{CLEAN} with \gls{ITASK}).} \gls{CLEAN}\slash\gls{ITASK} can implement all layers of the \gls{IOT} stack if the sensor nodes have the computational resources, as the Raspberry Pis do in \gls{CRS}. On resource constrained sensor nodes \gls{MTASK} are required to implement the perception and network layers, as on the Wemos minis in \gls{CWS}. 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 microprocessor 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}).
+We present \emph{the first comparison of two tierless \gls{IOT} languages: one designed for resource-constrained sensor nodes (\gls{CLEAN} with \gls{ITASK} and \gls{MTASK}), and the other for resource-rich sensor nodes (\gls{CLEAN} with \gls{ITASK}).} \gls{CLEAN}\slash\gls{ITASK} can implement all layers of the \gls{IOT} stack if the sensor nodes have the computational resources, as the Raspberry Pis do in \gls{CRS}. On resource constrained sensor nodes \gls{MTASK} are required to implement the perception and network layers, as on the \gls{WEMOS} minis in \gls{CWS}. 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 microprocessor 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}.
\subsection{Reflections}
--- /dev/null
+#!/bin/sh
+latexmk -pvc -cd -pdf "${@}"
repositories / phd-thesis.git / commitdiff