-v
}
VerbEnvir {
- lstinline lstlisting algorithm code spec lstClean lstHaskell lstHaskellLhstex lstArduino
+ lstinline lstlisting algorithm code spec lstClean lstHaskell lstHaskellLhstex lstArduino lstPython
}
WipeArg {
+ \cinline:{}
\cleaninline:{}
+ \pythoninline:{}
\haskellinline:{}
\haskelllshtexinline:{}
\arduinoinline:{}
--- /dev/null
+\documentclass[../thesis.tex]{subfiles}
+
+\begin{document}
+\ifSubfilesClassLoaded{
+ \pagenumbering{arabic}
+}{}
+
+\myappendix{chp:mtask_aux}{Auxiliary \texorpdfstring{\glsentrytext{MTASK}}{mTask} type classes}
+\lstset{basicstyle=\tt\footnotesize}
+\section{Peripherals}\label{sec:aux_peripherals}
+This section shows the peripherals not mentioned in \cref{chp:top4iot}.
+All constructors use \gls{HOAS} to create a type safe sensor object from a connection specification that can be used to interact with the sensor.
+The measurement tasks all yield unstable values contaning the measured value.
+The auxiliary functions such as calibration yield stable values indicating the result.
+Tasks suffixed with the backtick (\cleaninline{'}) indicate variants for which the timing interval can be specified (see \cref{chp:green_computing_mtask}).
+
+\subsection{Air quality sensor}
+The \gls{MTASK} language supports one type (\emph{CCS811} connected via \gls{I2C}) of air quality sensors that measures \gls{TVOC} (\unit{ppm}) and \gls{ECO2} ($\%$).
+Besides the constructor and tasks for the measurements there is also a calibration task that can be used to calibrate the sensor from temperature and humidity readings to increase the accuracy.
+The complete interface is shown in \cref{lst:mtask_aqs}.
+
+\begin{lstClean}[label={lst:mtask_aqs},caption={Air quality sensor interface in \gls{MTASK}.}]
+:: AirQualitySensor // abstract
+
+class AirQualitySensor v where
+ airqualitysensor :: I2CAddr ((v AirQualitySensor) -> Main (v a)) -> Main (v a)
+ tvoc` :: (TimingInterval v) (v AirQualitySensor) -> MTask v Int
+ tvoc :: (v AirQualitySensor) -> MTask v Int
+ co2` :: (TimingInterval v) (v AirQualitySensor) -> MTask v Int
+ co2 :: (v AirQualitySensor) -> MTask v Int
+ setEnvironmentalData :: (v AirQualitySensor) (v Real) (v Real) -> MTask v ()
+ setEnvFromDHT :: (v AirQualitySensor) (v DHT) -> MTask v ()
+\end{lstClean}
+
+\subsection{Gesture sensor}
+The \gls{MTASK} language supports one type (\emph{PAJ7620} connected via \gls{I2C}) of gesture sensors.
+The \emph{PAJ7620} contains an optical CMOS array that measures the reflection of the on-board \gls{IR} \gls{LED} to detect up to several different gestures.
+The complete interface containing the constructor and the measurement task is shown in \cref{lst:mtask_gesture}.
+
+\begin{lstClean}[label={lst:mtask_gesture},caption={Gesture sensor interface in \gls{MTASK}.}]
+:: GestureSensor // abstract
+:: Gesture = GNone | GRight | GLeft | GUp | GDown | GForward | GBackward
+ | GClockwise | GCountClockwise
+
+class GestureSensor v where
+ gestureSensor :: I2CAddr ((v GestureSensor) -> Main (v a)) -> Main (v a)
+ gesture` :: (TimingInterval v) (v GestureSensor) -> MTask v Gesture
+ gesture :: (v GestureSensor) -> MTask v Gesture
+\end{lstClean}
+
+\subsection{Light intensity sensor}
+The \gls{MTASK} language supports one type (\emph{BH1750} connected via \gls{I2C}) of light intensity sensors that measure the light intensity in \unit{lx}.
+The complete interface containing the constructor and the measurement task is shown in \cref{lst:mtask_light}.
+
+\begin{lstClean}[label={lst:mtask_light},caption={Light intensity sensor interface in \gls{MTASK}.}]
+:: LightSensor // abstract
+
+class LightSensor v where
+ lightsensor :: I2CAddr ((v LightSensor) -> Main (v b)) -> Main (v b)
+ light` :: (TimingInterval v) (v LightSensor) -> MTask v Real
+ light :: (v LightSensor) -> MTask v Real
+\end{lstClean}
+
+\subsection{Motion detection sensor}
+The \gls{MTASK} language supports motion sensing using a \gls{PIR} sensor through a type class that only contains macros.
+\gls{PIR} sensors detect motion by the \gls{IR} reflection through a number of fresnel lenses and communicates through a digital \gls{GPIO} pin.
+Therefore, a \gls{PIR} is nothing more than a \cleaninline{DPIN} according to \gls{MTASK} but for uniformity, a type class is available (see \cref{lst:mtask_pir}).
+
+\begin{lstClean}[label={lst:mtask_pir},caption={\Gls{PIR} sensor interface in \gls{MTASK}.}]
+:: PIR :== DPin
+
+class PIR v | step, expr, pinMode v & dio DPin v where
+ PIR :: DPin ((v PIR) -> Main (v b)) -> Main (v b) | expr, step, pinMode v
+
+ motion` :: (TimingInterval v) (v PIR) -> MTask v Bool
+ motion :: (v PIR) -> MTask v Bool | dio DPin v
+\end{lstClean}
+
+\subsection{Sound detection sensor}
+The \gls{MTASK} language supports motion sensing using one type of sensor (\emph{SEN-12642}) that outputs either a gate value through a digital \gls{GPIO} pin, the envelope (amplitude) through an analog \gls{GPIO} pin and an audio output.
+Only the sound level---i.e.\ the envelope---and the sound presence are available in \gls{MTASK} through a type class containing only macros.
+Therefore, a sound detector is nothing more than a tuple of a \cleaninline{DPin} for the gate value and an \cleaninline{APin} for the envelope (see \cref{lst:mtask_sound}).
+
+\begin{lstClean}[label={lst:mtask_sound},caption={Sound detection sensor interface in \gls{MTASK}.}]
+:: SoundDetector :== (DPin, APin)
+
+class SoundDetector v | tupl, expr, pinMode v & dio DPin v
+where
+ soundDetector :: DPin APin ((v SoundDetector) -> Main (v b)) -> Main (v b)
+
+ soundPresence` :: (TimingInterval v) (v SoundDetector) -> MTask v Bool
+ soundPresence :: (v SoundDetector) -> MTask v Bool | tupl v & dio DPin v
+
+ soundLevel` :: (TimingInterval v) (v SoundDetector) -> MTask v Bool
+ soundLevel :: (v SoundDetector) -> MTask v Bool | tupl, aio v
+\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 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}.
+
+\begin{lstClean}[label={lst:mtask_i2cbutton},caption={\Gls{I2C} button interface in \gls{MTASK}.}]
+:: I2CButton // abstract
+:: ButtonStatus = ButtonNone | ButtonPress | ButtonLong | ButtonDouble | ButtonHold
+
+class i2cbutton v where
+ i2cbutton :: I2CAddr ((v I2CButton) -> Main (v b)) -> Main (v b) | type b
+
+ AButton` :: (TimingInterval v) (v I2CButton) -> MTask v ButtonStatus
+ AButton :: (v I2CButton) -> MTask v ButtonStatus
+
+ BButton` :: (TimingInterval v) (v I2CButton) -> MTask v ButtonStatus
+ BButton :: (v I2CButton) -> MTask v ButtonStatus
+\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).
+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}.
+
+\begin{lstClean}[label={lst:mtask_ledmatrix},caption={\Gls{LED} matrix interface in \gls{MTASK}.}]
+:: LEDMatrix // abstract
+:: LEDMatrixInfo = { dataPin :: Pin, clockPin :: Pin }
+
+class LEDMatrix v where
+ ledmatrix :: LEDMatrixInfo ((v LEDMatrix) -> Main (v b)) -> Main (v b) | type b
+ LMDot :: (v LEDMatrix) (v Int) (v Int) (v Bool) -> MTask v ()
+ LMIntensity :: (v LEDMatrix) (v Int) -> MTask v ()
+ LMClear :: (v LEDMatrix) -> MTask v ()
+ LMDisplay :: (v LEDMatrix) -> MTask v ()
+\end{lstClean}
+
+\lstset{basicstyle=\tt}
+\input{subfilepostamble}
+\end{document}
\pagenumbering{arabic}
}{}
\mybackmatter{chp:acknowledgements}{Acknowledgements}%
-\begin{center}
+%\begin{center}
\noindent
Funding: Teun de Groot, Ton van Heusden
%Family: Parents (in law), brothers (in law), oma,
%
%Marie-José van Diem, Ellie Kimenai
-\end{center}
+
+The research carried out in this thesis was partly funded by the Royal Netherlands Navy.
+
+Additionally, this thesis acknowledges the support of the Erasmus+ Key Action 2 (Strategic partnership for higher education) project No. 2020--1--PT01--KA203--078646: ``SusTrainable --- Promoting Sustainability as a Fundamental Driver in Software Development Training and Education''.
+The information and views set out in this thesis are those of the author and do not necessarily reflect the official opinion of the European Union.
+Neither the European Union institutions and bodies nor any person acting on their behalf may be held responsible for the use which may be made of the information contained therein.
+
+Finally I want to thank all anonymous reviewers for the indispensable suggestions and remarks on all papers.
+%\end{center}
\input{subfilepostamble}
\end{document}
-v
}
VerbEnvir {
- lstinline lstlisting algorithm code spec lstClean lstHaskell lstHaskellLhstex lstArduino
+ lstinline lstlisting algorithm code spec lstClean lstHaskell lstHaskellLhstex lstArduino lstPython
}
WipeArg {
+ \cinline:{}
\cleaninline:{}
+ \pythoninline:{}
\haskellinline:{}
\haskelllshtexinline:{}
\arduinoinline:{}
Adding functions to the language is achieved by adding a multi-parameter class to the \gls{DSL}.
The type of the class function allows for the implementation to only allow first order function by supplying the arguments in a tuple.
Furthermore, by defining the \haskellinline{Main} type, the \gls{DSL} forces all functions to be defined at the top level and with the \haskellinline{:-} operator the syntax becomes usable.
-Finally, by defining the functions as a higher order abstract syntax (HOAS) type safety is achieved~\cite{pfenning_higher-order_1988,chlipala_parametric_2008}.
+Finally, by defining the functions as a \gls{HOAS} type safety is achieved~\cite{pfenning_higher-order_1988,chlipala_parametric_2008}.
The complete definition looks as follows:
\begin{lstHaskell}
\subsubsection{Quasiquotation}
Another key concept of \gls{TH} is Quasiquotation, the dual of splicing~\cite{bawden_quasiquotation_1999}.
While it is possible to construct entire programs using the provided data types, it is a little cumbersome.
-Using \emph{Oxford brackets} or single or double apostrophes, verbatim \gls{HASKELL} code can be entered that is converted automatically to the corresponding AST nodes easing the creation of language constructs.
+Using \emph{Oxford brackets} (\verb#[|# \ldots\verb#|]#) or single or double apostrophes, verbatim \gls{HASKELL} code can be entered that is converted automatically to the corresponding AST nodes easing the creation of language constructs.
Depending on the context, different quasiquotes are used:
\begin{itemize*}
- \item \haskellinline{[|...|]} or \haskellinline{[e|...|]} for expressions
- \item \haskellinline{[d|...|]} for declarations
- \item \haskellinline{[p|...|]} for patterns
- \item \haskellinline{[t|...|]} for types
+ \item \haskellinline{[\|...\|]} or \haskellinline{[e\|...\|]} for expressions
+ \item \haskellinline{[d\|...\|]} for declarations
+ \item \haskellinline{[p\|...\|]} for patterns
+ \item \haskellinline{[t\|...\|]} for types
\item \haskellinline{'...} for function names
\item \haskellinline{''...} for type names
\end{itemize*}.
The syntax burden of \glspl{EDSL} can be reduced using quasiquotation.
In \gls{TH}, quasiquotation is a convenient way to create \gls{HASKELL} language constructs by entering them verbatim using Oxford brackets.
However, it is also possible to create so-called custom quasiquoters~\cite{mainland_why_2007}.
-If the programmer writes down a fragment of code between \emph{tagged} Oxford brackets, the compiler executes the associated quasiquoter functions at compile time.
+If the programmer writes down a fragment of code between tagged \emph{Oxford brackets}, the compiler executes the associated quasiquoter functions at compile time.
A quasiquoter is a value of the following data type:
\begin{lstHaskell}
}
\end{lstHaskell}
-The code between \emph{dsl} brackets (\haskellinline{[dsl|...|]}) is preprocessed by the \haskellinline{dsl} quasiquoter.
+The code between \emph{dsl} brackets (\haskellinline{[dsl\|...\|]}) is preprocessed by the \haskellinline{dsl} quasiquoter.
Because the functions are executed at compile time, errors---thrown using the \haskellinline{MonadFail} instance of the \haskellinline{Q} monad---in these functions result in compile time errors.
The AST nodes produced by the quasiquoter are inserted into the location and checked as if they were written by the programmer.
To illustrate writing a custom quasiquoter, we show an implementation of a quasiquoter for binary literals.
The \haskellinline{bin} quasiquoter is only defined for expressions and parses subsequent zeros and ones as a binary number and splices it back in the code as a regular integer.
-Thus, \haskellinline{[bin|101010|]} results in the literal integer expression \haskellinline{42}.
+Thus, \haskellinline{[bin\|101010\|]} results in the literal integer expression \haskellinline{42}.
If an invalid character is used, a compile-time error is shown.
The quasiquoter is defined as follows:
% Acronyms
+\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{CRS}{PRS}{clean raspberry pi supersensor}
-\newacronym{CWS}{PWS}{clean wemos supersensor}
+\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{QDSL}{QDSL}{quoted \acrshort{DSL}}
\newacronym{FP}{FP}{functional programming}
+\newacronym{FRP}{FRP}{functional reactive programming}
\newacronym{GADT}{GADT}{generalised \acrshort{ADT}}
-\newacronym{GHC}{GHC}{Glasgow Haskell Compiler}
+\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{PRS}{PRS}{python raspberry pi supersensor}
-\newacronym{PWS}{PWS}{(micro)python wemos supersensor}%chktex 36
+\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{TH}{TH}{Template Haskell}
-\newacronym{TTH}{TTH}{Typed \acrlong{TH}}
\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}
% Glossaries
\newglossaryentry{MTASK}{%
name=I\textsuperscript{2}C,
description={is a simple serial communication protocol often used to connect sensors to microprocessors}
}
+\newglossaryentry{SPI}{
+ name=SPI,
+ description={is a synchronous serial communication protocol often used to connect sensors to microprocessors}
+}
\newglossaryentry{TINYML}{
name=TinyML,
description={is a deep learning framework for microprocessors}
name=FreeRTOS,
description={is an open-source \gls{RTOS} for microprocessors}
}
+\newglossaryentry{ONEWIRE}{
+ name=1-wire,
+ description={is simple single wire communication protocol often used to connect sensors to microprocessors}
+}
+\newglossaryentry{JSON}{
+ name=JSON,
+ description={(JavaScript Object Notation) is a open data interchange format using human readable text}
+}
+\newglossaryentry{MQTT}{
+ name=MQTT,
+ description={(originally MQ Telemetry Transport) is a publish-subscribe network protocol designed for resource constrained devices}
+}
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~\cite{elliott_compiling_2003}.
In fact, \gls{ITASK} and \gls{MTASK} are both heterogeneous \glspl{EDSL}.
-\section{Functional programming}\label{ssec:functional programming}
-\Gls{FP} is \ldots
-\Gls{FP} languages are naturally suitable as a host language for \gls{DSL} embedding because of their rich type systems and minimal and extensible syntax~\cite{gibbons_functional_2015}.
-
\section{Task-oriented programming}
\Gls{TOP} is a declarative programming paradigm designed to model interactive systems~\cite{plasmeijer_task-oriented_2012}.
Instead of dividing problems into layers or tiers, as is done in \gls{IOT} architectures as well, it deals with separation of concerns in a novel way.
The thesis wraps up with \cref{chp:conclusion} that provides a conclusion and an outlook on future work.
\subsection{\Cref{prt:dsl}: Domain-specific languages}
-This movement is a cumulative or paper-based movement that focusses on techniques for embedding \glspl{DSL} in functional programming lanugages.
+This movement is a cumulative---paper-based---movement that focusses on techniques for embedding \glspl{DSL} in functional programming lanugages.
After reading the first chapter, subsequent chapters in this movement are readable as independently.
\subsubsection{\Cref{chp:dsl_embedding_techniques}}
-This chapter shows all the basic techniques and compares the properties of several embedding methods.
+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 background for the subsequent chapters in the movement.
\subsubsection{\Cref{chp:classy_deep_embedding}}
This chapter is based on the paper: \emph{First-Class Data Types in Shallow Embedded Domain-Specific Languages using Metaprogramming}~\todo{cite when accepted}.
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.
-
-\subsubsection{\Cref{chp:strongly-typed_multi-view_stack-based_computations}} shows how to use advanced \gls{DSL} techniques to embed type safe stack-based computations in a host language.
-This chapter is based on the paper: \emph{Strongly-Typed Multi-View Stack-Based Computations}~\todo{cite when accepted}.
-\todo{Zal ik dit paper wel opnemen? Aangezien Pieter het grotendeels gedaan heeft?}
-
-I supported Pieter Koopman in performing the research in this paper by writing some of the software.
-The paper was mostly written by Pieter Koopman\todo{probably will be}.
+%
+%\subsubsection{\Cref{chp:strongly-typed_multi-view_stack-based_computations}} shows how to use advanced \gls{DSL} techniques to embed type safe stack-based computations in a host language.
+%This chapter is based on the paper: \emph{Strongly-Typed Multi-View Stack-Based Computations}~\todo{cite when accepted}.
+%\todo{Zal ik dit paper wel opnemen? Aangezien Pieter het grotendeels gedaan heeft?}
+%
+%I supported Pieter Koopman in performing the research in this paper by writing some of the software.
+%The paper was mostly written by Pieter Koopman\todo{probably will be}.
\subsection{\Cref{prt:top}: Task-oriented \texorpdfstring{\acrlong{IOT}}{internet of things} programming }
This part is a monograph focussing on \glspl{TOP} for the \gls{IOT}.
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. I wrote the lecture notes, prepared the other half of the lecture, the assignments and the practical session.
+ 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
# Clean morewords file
push @generated_exts, 'mw';
-# Clean morewords file
+# Clean standalone file
push @generated_exts, 'sta';
# Clean bbl file as well
$pdf_mode = 1;
-$output_directory = "aux";
+$pdflatex = 'pdflatex %O %S || (echo === Deleting %Y%R.sta ...; rm -v %Y%R.sta; false)';
\lstdefinelanguage[Arduino]{C++}[11]{C++}{%
- morekeywords={HIGH,LOW,OUTPUT,INPUT,INPUT\_PULLUP,%
+ morekeywords={%
+ %HIGH,LOW,OUTPUT,INPUT,INPUT\_PULLUP,%
D0,D1,D2,D3,D4,D5,D6,D7,D7,D8,D9,D10,D11,D12,D13,A0,A1,A2,A3,A4,A5,A6,A7,%
pinMode,digitalWrite,digitalRead,delay,millis,%
},
morestring=[s]{['}{']},
literate=%
{\_}{{\raisebox{.15ex}{\_}}}1
- {~}{{\raisebox{-.6ex}{\textasciitilde}}}1
- {...}{{$\cdots$}}1
+% {\~}{{\raisebox{-.6ex}{\textasciitilde}}}1
+ {~}{{\textasciitilde}}1
+ {...}{{$\cdots$}}3
{->}{{$\shortrightarrow$}}2
{=>}{{$\Rightarrow$}}2
}
{<-}{{$\shortleftarrow$}}2
{=>}{{$\Rightarrow$}}2
{<=}{{$\Leftarrow$}}2
- {...}{{$\cdots$}}1 %chktex 11
+ {...}{{$\cdots$}}3 %chktex 11
{\[p|}{{$\llbracket_p$}}2
{\[d|}{{$\llbracket_d$}}2
{\[t|}{{$\llbracket_t$}}2
\pagenumbering{arabic}
}{}
-\mychapter{chp:top4iot}{Introduction to \gls{IOT} programming}
+\mychapter{chp:top4iot}{Introduction to \texorpdfstring{\gls{IOT}}{IoT} programming}
\todo{betere chapter naam}
\begin{chapterabstract}
This chapter introduces \gls{MTASK} and puts it into perspective compared to traditional microprocessor programming.
\end{subfigure}%
\begin{subfigure}[b]{.5\linewidth}
\begin{lstClean}[caption={Blink program.},label={lst:blinkImp}]
-
blink :: Main (MTask v ()) | mtask v
blink =
declarePin D2 PMOutput \d2->
}
void loop() {
- blink (1, 500);
- blink (2, 300);
- blink (3, 800);
+ blink (D1, 500);
+ blink (D2, 300);
+ blink (D3, 800);
}\end{lstArduino}
Unfortunately, this does not work because the \arduinoinline{delay} function blocks all further execution.
}
void loop() {
- blink(1, 500, &led1, &st1);
- blink(2, 300, &led2, &st1);
- blink(3, 800, &led3, &st1);
+ blink(D1, 500, &led1, &st1);
+ blink(D2, 300, &led2, &st1);
+ blink(D3, 800, &led3, &st1);
}\end{lstArduino}
This method is very error prone, requires a lot of pointer juggling and generally results into spaghetti code.
Furthermore, it is very difficult to represent dependencies between threads, often state machines have to be explicitly programmed by hand to achieve this.
-\section{Blinking in \gls{MTASK}}
+\section{Blinking in \texorpdfstring{\gls{MTASK}}{mTask}}
The \cleaninline{delay} \emph{task} does not block the execution but \emph{just} emits no value when the target waiting time has not yet passed and emits a stable value when the time is met.
In contrast, the \cleaninline{delay} \emph{function} on the \gls{ARDUINO} is blocking which prohibits interleaving.
To make code reuse possible and make the implementation more intuitive, the blinking behaviour is lifted to a recursive function instead of using the imperative \cleaninline{rpeat} construct.
.||. blink (true, d3, lit 800)
}\end{lstClean}
-\mychapter{chp:mtask_dsl}{The \gls{MTASK} \gls{DSL}}
+\mychapter{chp:mtask_dsl}{The \texorpdfstring{\gls{MTASK}}{mTask} \texorpdfstring{\gls{DSL}}{DSL}}
\begin{chapterabstract}
This chapter serves as a complete guide to the \gls{MTASK} language, from an \gls{MTASK} programmer's perspective.
\end{chapterabstract}
The \gls{MTASK} system is a \gls{TOP} programming environment for programming microprocessors.
It is implemented as an \gls{EDSL} in \gls{CLEAN} using class-based---or tagless-final---embedding (See \cref{ssec:tagless}).
Due to the nature of the embedding technique, it is possible to have multiple interpretations of---or views on---programs written in the \gls{MTASK} language.
+The following interpretations are available for \gls{MTASK}.
\begin{itemize}
\item Pretty printer
Furthermore, with special language constructs, \glspl{SDS} can be shared between \gls{MTASK} and \gls{ITASK} programs.
\end{itemize}
+When using the compiler interpretation in conjunction with the \gls{ITASK} integration, \gls{MTASK} is a heterogeneous \gls{DSL}.
+I.e.\ some components---e.g.\ the \gls{RTS} on the microprocessor---is largely unaware of the other components in the system.
+Furthermore, it is executed on a completely different architecture.
+The \gls{MTASK} language consists of a host language---a simply-typed $\lambda$-calculua with support for some basic types, function definition and data types (see \cref{sec:expressions})---enriched with a task language (see \cref{sec:top}).
+
\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 2KiB of \gls{RAM} so class constraints are therefore added to the \gls{DSL} functions.
+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.
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.
There are also \gls{MTASK} extensions that not every interpretation implements such as peripherals and integration with \gls{ITASK}.
\Cref{lst:constraints} contains the definitions for the type constraints and shows some example type signatures for typical \gls{MTASK} expressions and tasks.
+\todo{uitleggen}
\begin{lstClean}[caption={Classes and class collections for the \gls{MTASK} language.},label={lst:constraints}]
+:: Main a = { main :: a }
+:: In a b = (In) infix 0 a b
+
class type t | iTask, ... ,fromByteCode, toByteCode t
class basicType t | type t where ...
In {main=mainexpr}
\end{lstClean}
-\section{Expressions}
+\section{Expressions}\label{sec:expressions}
\Cref{lst:expressions} shows the \cleaninline{expr} class containing the functionality to lift values from the host language to the \gls{MTASK} language (\cleaninline{lit}); perform number and boolean arithmetics; do comparisons; and conditional execution.
For every common arithmetic operator in the host language, an \gls{MTASK} variant is present, suffixed by a period to not clash with \gls{CLEAN}'s builtin operators.
Conversion to-and-fro data types is available through the overloaded functions \cleaninline{int}, \cleaninline{long} and \cleaninline{real}.
-\begin{lstClean}
+\begin{lstClean}[caption={Type conversion functions in \gls{MTASK}.}]
class int v a :: (v a) -> v Int
class real v a :: (v a) -> v Real
class long v a :: (v a) -> v Long
\end{lstClean}
Finally, values from the host language must be explicitly lifted to the \gls{MTASK} language using the \cleaninline{lit} function.
-For convenience, there are many lower-cased macro definitions for often used constants as can be seen in \cref{lst:convenience_lits}
-
-\begin{lstClean}[label={lst:convenience_lits}]
-// Booleans
-true :== lit True
-false :== lit False
+For convenience, there are many lower-cased macro definitions for often used constants such as \cleaninline{true :== lit True}, \cleaninline{false :== lit False}, \etc.
+
+\Cref{lst:example_exprs} shows some examples of these expressions.
+\cleaninline{e0} defines the literal $42$, \cleaninline{e1} calculates the literal $42.0$ using real numbers.
+\cleaninline{e2} compares \cleaninline{e0} and \cleaninline{e1} as integers and if they are equal it returns the \cleaninline{e2}$/2$ and \cleaninline{e0} otherwise.
+\cleaninline{approxEqual} performs an approximate equality---albeit not taking into account all floating point pecularities---and demonstrates that \gls{CLEAN} can be used as a macro language.
+When calling \cleaninline{approxEqual} in an \gls{MTASK} function, the resulting code is inlined.
+
+\begin{lstClean}[label={lst:example_exprs},caption={Example \gls{MTASK} expressions.}]
+e0 :: v Int | expr v
+e0 = lit 42
+
+e1 :: v Real | expr v
+e1 = lit 38.0 + real (lit 4)
+
+e2 :: v Int | expr v
+e2 = if' (e0 ==. int e1)
+ (int e1 /. lit 2) e0
+
+approxEqual :: (v Real) (v Real) (v Real) -> v Real | expr v
+approxEqual x y eps = if' (x == y) true
+ ( if' (x > y)
+ (y -. x < eps)
+ (x -. y < eps)
+ )
+\end{lstClean}
+%jona
+%jaunda
+
+\subsection{Data Types}
+Most of \gls{CLEAN}'s basic types have been mapped on \gls{MTASK} types.
+However, it can be useful to have access to compound types as well.
+All types in \gls{MTASK} must have a fixed size representation on the stack so sum types are not (yet) supported.
+While it is possible to lift types using the \cleaninline{lit} function, you cannot do anything with the types besides passing them around but they are being produced by some parallel task combinators (see \cref{sssec:combinators_parallel}).
+To be able to use types as first class citizens, constructors and field selectors are required.
+\Cref{lst:tuple_exprs} shows the scaffolding for supporting tuples in \gls{MTASK}.
+Besides the constructors and field selectors, there is also a helper function available that transforms a function from a tuple of \gls{MTASK} expressions to an \gls{MTASK} expression of a tuple.
+
+\begin{lstClean}[label={lst:tuple_exprs},caption={Tuple constructor and field selectors in \gls{MTASK}.}]
+class tupl v where
+ tupl :: (v a) (v b) -> v (a, b) | type a & type b
+ first :: (v (a, b)) -> v a | type a & type b
+ second :: (v (a, b)) -> v b | type a & type b
+
+ tupopen f :== \v->f (first v, second v)
\end{lstClean}
\subsection{Functions}
-Functions in \gls{MTASK} are defined
+Adding functions to the language is achieved by one multi-parameter class to the \gls{DSL}.
+By using \gls{HOAS}, both the function definition and the calls to the function can be controlled by the \gls{DSL}~\cite{pfenning_higher-order_1988,chlipala_parametric_2008}.
+As \gls{MTASK} only supports first-order functions and does not allow partial function application.
+Using a type class of this form, this restriction can be enforced on the type level.
+Instead of providing one instance for all functions, a single instance per function arity is defined.
+Also, \gls{MTASK} only supports top-level functions which is enforced by the \cleaninline{Main} box.
+The definition of the type class and the instances for an example interpretation are as follows:
+\todo{uitbreiden}
+
+\begin{lstClean}[caption={Functions in \gls{MTASK}.}]
+class fun a v :: ((a -> v s) -> In (a -> v s) (Main (MTask v u)))
+ -> Main (MTask v u)
+
+instance fun () Inter where ...
+instance fun (Inter a) Inter | type a where ...
+instance fun (Inter a, Inter b) Inter | type a where ...
+instance fun (Inter a, Inter b, Inter c) Inter | type a where ...
+...
+\end{lstClean}
+
+Deriving how to define and use functions from the type is quite the challenge even though the resulting syntax is made easier using the infix type \cleaninline{In}.
+\Cref{lst:function_examples} show the factorial function, a tail-call optimised factorial function and a function with zero arguments to demonstrate the syntax.
+Splitting out the function definition for each single arity means that that for every function arity and combination of arguments, a separate class constraint must be created.
+Many of the often used functions are already bundled in the \cleaninline{mtask} class constraint collection.
+\cleaninline{factorialtail} shows a manually added class constraint.
+Definiting zero arity functions is shown in the \cleaninline{zeroarity} expression.
+Finally, \cleaninline{swapTuple} shows an example of a tuple being swapped.
+
+\begin{lstClean}[label={lst:function_examples},caption={Function examples in \gls{MTASK}.}]
+factorial :: Main (v Int) | mtask v
+factorial =
+ fun \fac=(\i->if' (i <. lit 1)
+ (lit 1)
+ (i *. fac (i -. lit 1)))
+ In {main = fac (lit 5) }
+
+factorialtail :: Main (v Int) | mtask v & fun (v Int, v Int) v
+factorialtail =
+ fun \facacc=(\(acc, i)->if' (i <. lit 1)
+ acc
+ (fac (acc *. i, i -. lit 1)))
+ In fun \fac=(\i->facacc (lit 1, i))
+ In {main = fac (lit 5) }
+
+zeroarity :: Main (v Int) | mtask v
+zeroarity =
+ fun \fourtytwo=(\()->lit 42)
+ In fun \add=(\(x, y)->x +. y)
+ In {main = add (fourtytwo (), lit 9)}
+
+swapTuple :: Main (v (Int, Bool)) | mtask v
+swapTuple =
+ fun \swap=(tupopen \(x, y)->tupl y x)
+ In {main = swap (tupl true (lit 42)) }
+\end{lstClean}
+
+\section{Tasks}\label{sec:top}
+\Gls{MTASK}'s task language can be divided into three categories, namely
+\begin{enumerate*}
+ \item Basic tasks, in most \gls{TOP} systems, the basic tasks are called editors, modelling the interactivity with the user.
+ In \gls{MTASK}, there are no \emph{editors} in that sense but there is interaction with the outside world through microprocessor peripherals such as sensors and actuators.
+ \item Task combinators provide a way of describing the workflow.
+ They combine one or more tasks into a compound task.
+ \item \glspl{SDS} in \gls{MTASK} can be seen as references to data that can be shared using many-to-many communication and are only accessible from within the task language to ensure atomicity.
+\end{enumerate*}
+
+As \gls{MTASK} is integrated with \gls{ITASK}, the same stability distinction is made for task values.
-\section{Tasks}
\subsection{Basic tasks}
+The most rudimentary basic tasks are the \cleaninline{rtrn} and \cleaninline{unstable} tasks.
+They lift the value from the \gls{MTASK} expression language to the task domain either as a stable value or an unstable value.
+
+\begin{lstClean}[label={lst:basic_tasks},caption={Function examples in \gls{MTASK}.}]
+class rtrn v :: (v t) -> MTask v t | type t
+class unstable v :: (v t) -> MTask v t | type t
+\end{lstClean}
+
+\todo{examples}
+
\subsubsection{Peripherals}
+For every sensor or actuator, basic tasks are available that allow interaction with the specific peripheral.
+The type classes for these tasks are not included in the \cleaninline{mtask} class collection as not all devices nor all language interpretations have such peripherals connected.
+\todo{Historically, peripheral support has been added \emph{by need}.}
+
+\Cref{lst:dht} and \cref{lst:gpio} show the type classes for \glspl{DHT} sensors and \gls{GPIO} access.
+Other peripherals have similar interfaces, they are available in the \cref{sec:aux_peripherals}.
+For the \gls{DHT} sensor there are two basic tasks, \cleaninline{temperature} and \cleaninline{humidity}, that---will given a \cleaninline{DHT} object---produce a task that yields the observed temperature in \unit{\celcius} or relative humidity as a percentage as an unstable value.
+Currently, two different types of \gls{DHT} sensors are supported, the \emph{DHT} family of sensors connect through $1$-wire protocol and the \emph{SHT} family of sensors connected using \gls{I2C} protocol.
+Creating such a \cleaninline{DHT} object is very similar to creating functions in \gls{MTASK} and uses \gls{HOAS} to make it type safe.
+
+\begin{lstClean}[label={lst:dht},caption{The \gls{MTASK} interface for \glspl{DHT} sensors.}]
+:: DHT //abstract
+:: DHTInfo
+ = DHT_DHT Pin DHTtype
+ | DHT_SHT I2CAddr
+:: DHTtype = DHT11 | DHT21 | DHT22
+class dht v where
+ DHT :: DHTInfo ((v DHT) -> Main (v b)) -> Main (v b) | type b
+ temperature :: (v DHT) -> MTask v Real
+ humidity :: (v DHT) -> MTask v Real
+
+measureTemp :: Main (MTask v Real) | mtask v & dht v
+measureTemp = DHT (DHT_SHT (i2c 0x36)) \dht->
+ {main=temperature dht}
+\end{lstClean}
+
+\Gls{GPIO} access is divided into three classes: analog, digital and pin modes.
+For all pins and pin modes an \gls{ADT} is available that enumerates the pins.
+The analog \gls{GPIO} pins of a microprocessor are connected to an \gls{ADC} that translates the voltage to an integer.
+Analog \gls{GPIO} pins can be either read or written to.
+Digital \gls{GPIO} pins only report a high or a low value.
+The type class definition is a bit more complex since analog \gls{GPIO} pins can be used as digital \gls{GPIO} pins as well.
+Therefore, if the \cleaninline{p} type implements the \cleaninline{pin} class---i.e.\ either \cleaninline{APin} or \cleaninline{DPin}---the \cleaninline{dio} class can be used.
+\Gls{GPIO} pins usually operate according to a certain pin mode that states whether the pin acts as an input pin, an input with an internal pull-up resistor or an output pin.
+This setting can be applied using the \cleaninline{pinMode} class by hand or by using the \cleaninline{declarePin} \gls{GPIO} pin constructor.
+Setting the pin mode is a task that immediately finisheds and fields a stable unit value.
+Writing to a pin is also a task that immediately finishes but yields the written value instead.
+Reading a pin is a task that yields an unstable value---i.e.\ the value read from the actual pin.
+
+\begin{lstClean}[label={lst:gpio},caption{The \gls{MTASK} interface for \gls{GPIO} access.}]
+:: APin = A0 | A1 | A2 | A3 | A4 | A5
+:: DPin = D0 | D1 | D2 | D3 | D4 | D5 | D6 | D7 | D8 | D9 | D10 | D11 | D12 | D13
+:: PinMode = PMInput | PMOutput | PMInputPullup
+:: Pin = AnalogPin APin | DigitalPin DPin
+class pin p :: p -> Pin
+
+class aio v where
+ writeA :: (v APin) (v Int) -> MTask v Int
+ readA :: (v APin) -> MTask v Int
+
+class dio p v | pin p where
+ writeD :: (v p) (v Bool) -> MTask v Bool
+ readD :: (v p) -> MTask v Bool | pin p
+
+class pinMode v where
+ pinMode :: (v PinMode) (v p) -> MTask v () | pin, type p
+ declarePin :: p PinMode ((v p) -> Main (v a)) -> Main (v a) | pin p & type a
+\end{lstClean}
+\todo{onder Task Combinators verplaatsen zodat de voorbeeldjes leuker kunnen zijn?}
+
\subsection{Task combinators}
-\subsubsection{Parallel}
+\subsubsection{Parallel}\label{sssec:combinators_parallel}
+\begin{lstClean}[label={lst:mtask_parallel},caption{Parallel task combinators in \gls{MTASK}.}]
+class (.&&.) infixr 4 v :: (MTask v a) (MTask v b) -> MTask v (a, b) | type a & type b
+class (.||.) infixr 3 v :: (MTask v a) (MTask v a) -> MTask v a | type a
+\end{lstClean}
+
\subsubsection{Sequential}
+\begin{lstClean}[label={lst:mtask_sequential},caption{Sequential task combinators in \gls{MTASK}.}]
+class step v | expr v where
+ (>>*.) infixl 1 :: (MTask v t) [Step v t u] -> MTask v u | type u & type t
+ (>>=.) infixl 0 :: (MTask v t) ((v t) -> MTask v u) -> MTask v u | expr v & type u & type t
+ (>>|.) infixl 0 :: (MTask v t) (MTask v u) -> MTask v u | expr v & type u & type t
+ (>>|.) ma mb = ma >>*. [IfStable (\_->lit True) \_->mb]
+ (>>~.) infixl 0 :: (MTask v t) ((v t) -> MTask v u) -> MTask v u | expr v & type u & type t
+ (>>~.) ma amb = ma >>*. [IfValue (\_->lit True) amb]
+ (>>..) infixl 0 :: (MTask v t) (MTask v u) -> MTask v u | expr v & type u & type t
+ (>>..) ma mb = ma >>*. [IfValue (\_->lit True) \_->mb]
+
+:: Step v t u
+ = IfValue ((v t) -> v Bool) ((v t) -> MTask v u)
+ | IfStable ((v t) -> v Bool) ((v t) -> MTask v u)
+ | IfUnstable ((v t) -> v Bool) ((v t) -> MTask v u)
+ | Always (MTask v u)
+\end{lstClean}
+
\subsubsection{Miscellaneous}
-\subsection{\glspl{SDS}}
+\begin{lstClean}[label={lst:mtask_misc},caption{Miscellaneous task combinators in \gls{MTASK}.}]
+class rpeat v where
+ /**
+ * Executes the task until it yields a stable value, after which it is restarted.
+ *
+ * @param task
+ * @param the transformed task
+ */
+ rpeat :: (MTask v a) -> MTask v a | type a
+ rpeat t :== rpeatEvery Default t
+ /**
+ * Executes the task until it yields a stable value, after which it is restarted at most once every given timing interval.
+ *
+ * @param restarting interval
+ * @param task
+ * @param the transformed task
+ */
+ rpeatEvery :: (TimingInterval v) (MTask v a) -> MTask v a | type a
+
+/**
+ * The basic task that waits for a specified amount of time
+ *
+ * @var view
+ * @param number of milliseconds to wait
+ * @result task that yields
+ * - when the time has passed: a stable value with the number of milliseconds it overshot the waiting time
+ * - when the time has not passed: an unstable value with the number of milliseconds it still needs to wait
+ */
+class delay v :: (v n) -> MTask v Long | type n & long v n
+\end{lstClean}
+
+\subsection{\texorpdfstring{\Acrlongpl{SDS}}{Shared data sources}}
-\mychapter{chp:green_computing_mtask}{Green computing with \gls{MTASK}}
+\mychapter{chp:green_computing_mtask}{Green computing with \texorpdfstring{\gls{MTASK}}{mTask}}
-\mychapter{chp:integration_with_itask}{Integration with \gls{ITASK}}
+\mychapter{chp:integration_with_itask}{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}
\section{Devices}
-\section{Lift tasks}
-\section{Lift \glspl{SDS}}
+\section{Lifting tasks}
+\section{Lifting \texorpdfstring{\acrlongpl{SDS}}{shared data sources}}
\mychapter{chp:implementation}{Implementation}
IFL19 paper, bytecode instructieset~\cref{chp:bytecode_instruction_set}
-\section{Integration with \gls{ITASK}}
+\section{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}
IFL18 paper stukken
-\chapter{\gls{MTASK} history}
-\section{Generating \glsentrytext{C}/\glsentrytext{CPP} code}
+\chapter{\texorpdfstring{\gls{MTASK}}{mTask} history}
+\section{Generating \texorpdfstring{\gls{C}/\gls{CPP}}{C/C++} code}
A first throw at a class-based shallowly \gls{EDSL} for microprocessors was made by Pieter Koopman and Rinus Plasmijer in 2016~\cite{plasmeijer_shallow_2016}.
The language was called \gls{ARDSL} and offered a type safe interface to \gls{ARDUINO} \gls{CPP} dialect.
A \gls{CPP} code generation backend was available together with an \gls{ITASK} simulation backend.
Some time later in the 2015 CEFP summer school, an extended version was created that allowed the creation of imperative tasks, \glspl{SDS} and the usage of functions~\cite{koopman_type-safe_2019}.
The name then changed from \gls{ARDSL} to \gls{MTASK}.
-\section{Integration with \glsentrytext{ITASK}}
+\section{Integration with \texorpdfstring{\gls{ITASK}}{iTask}}
Mart Lubbers extended this in his Master's Thesis by adding integration with \gls{ITASK} and a bytecode compiler to the language~\cite{lubbers_task_2017}.
\Gls{SDS} in \gls{MTASK} could be accessed on the \gls{ITASK} server.
In this way, entire \gls{IOT} systems could be programmed from a single source.
It was shown by Matheus Amazonas Cabral de Andrade that it was possible to build real-life \gls{IOT} systems with this integration~\cite{amazonas_cabral_de_andrade_developing_2018}.
Moreover, a course on the \gls{MTASK} simulator was provided at the 2018 CEFP/3COWS winter school in Ko\v{s}ice, Slovakia~\cite{koopman_simulation_2018}.
-\section{Transition to \glsentrytext{TOP}}
+\section{Transition to \texorpdfstring{\gls{TOP}}{TOP}}
The \gls{MTASK} language as it is now was introduced in 2018~\cite{koopman_task-based_2018}.
This paper updated the language to support functions, tasks and \glspl{SDS} but still compiled to \gls{CPP} \gls{ARDUINO} code.
Later the bytecode compiler and \gls{ITASK} integration was added to the language~\cite{lubbers_interpreting_2019}.
One reason for this is that a lot of design patterns that are difficult using standard means are for free in \gls{TOP} (e.g.\ multithreading).
In 2019, the CEFP summer school in Budapest, Hungary hosted a course on developing \gls{IOT} applications with \gls{MTASK} as well~\cite{lubbers_writing_2019}.
-\section{\glsentrytext{TOP}}
+\section{\texorpdfstring{\gls{TOP}}{TOP}}
In 2022, the SusTrainable summer school in Rijeka, Croatia hosted a course on developing greener \gls{IOT} applications using \gls{MTASK} as well (the lecture notes are to be written).
Several students worked on extending \gls{MTASK} with many useful features:
Erin van der Veen did preliminary work on a green computer analysis, built a simulator and explored the possibilities for adding bounded datatypes~\cite{veen_van_der_mutable_2020}; Michel de Boer investigated the possibilities for secure communication channels~\cite{boer_de_secure_2020}; and Sjoerd Crooijmans added abstractions for low-power operation to \gls{MTASK} such as hardware interrupts and power efficient scheduling~\cite{crooijmans_reducing_2021}.
In 2023, the SusTrainable summer school in Coimbra, Portugal will host a course on \gls{MTASK} as well.
-\section{\glsentrytext{MTASK} in practise}
+\section{\texorpdfstring{\gls{MTASK}}{mTask} in practise}
Funded by the Radboud-Glasgow Collaboration Fund, collaborative work was executed with Phil Trinder, Jeremy Singer and Adrian Ravi Kishore Ramsingh.
An existing smart campus application was developed using \gls{MTASK} and quantitively and qualitatively compared to the original application that was developed using a traditional \gls{IOT} stack~\cite{lubbers_tiered_2020}.
The collaboration is still ongoing and a journal article is under review comparing four approaches for the edge layer: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK} and \gls{MTASK}.
\usepackage{amsmath} % extra math
\usepackage{amssymb} % extra math symbols
\usepackage{relsize} % \smaller command
-\usepackage{atveryend} % \smaller command
+\usepackage{siunitx} % typeset units
+\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{::}}
paperwidth=17cm,
paperheight=24cm,
}
+\usepackage{pdflscape}
\usepackage{float}
\usepackage{fancyhdr} % Custom headers and footers
%\pagestyle{headings}
% Bibliography
\usepackage{bibentry} % Cite bib entry completely
\nobibliography*
-\bibliographystyle{alpha}
+\usepackage{natbib} % Cite bib entry completely
+\setlength{\bibsep}{0.0pt}
+%\bibliographystyle{alpha}
+\bibliographystyle{abbrvnat}
% Graphics
\usepackage{graphicx} % Images
\graphicspath{{img/},{introduction/img}}
+\graphicspath{{img/},{introduction/img},{tiered_vs._tierless_programming/img}}
\usepackage{caption} % subfigures
\usepackage{subcaption}
+\usepackage{rotating}
\newcommand{\orcid}[1]{\href{https://orcid.org/#1}{\hspace{1mm}\includegraphics[width=1em]{orcid}\hspace{2mm} https://orcid.org/#1}}
% Tables
% General listings settings
\lstset{%
basewidth=0.5em,
- basicstyle=\tt,
+ basicstyle=\tt\small,
breakatwhitespace=false,
breaklines=true,
captionpos=b,
columns=[c]fixed,
+% columns=flexible,
commentstyle=\sl,
escapeinside={[+}{+]}, % chktex 9
frame=L,
stringstyle=\it,
tabsize=4,
upquote=true,
+ numberstyle=\tiny,
}
\usepackage{lstlangclean}
\usepackage{lstlanghaskell}
\usepackage{lstlanghaskelllhstex}
\usepackage{lstlangarduino}
-\newcommand{\cinline}[1]{\lstinline[language=c,postbreak=]|#1|}
-\newcommand{\arduinoinline}[1]{\lstinline[language={[Arduino]C++},postbreak=]|#1|}
-\newcommand{\cleaninline}[1]{\lstinline[language=Clean,postbreak=]|#1|}
-\newcommand{\haskellinline}[1]{\lstinline[language=Haskell,style=haskell,postbreak=]|#1|}
-\newcommand{\haskelllhstexinline}[1]{\lstinline[language=Haskell,style=haskelllhstex,postbreak=]|#1|}
+\newcommand{\cinline}[1]{\lstinline[language=c,basicstyle=\tt,postbreak=]|#1|}
+\newcommand{\arduinoinline}[1]{\lstinline[language={[Arduino]C++},basicstyle=\tt,postbreak=]|#1|}
+\newcommand{\pythoninline}[1]{\lstinline[language=Python,basicstyle=\tt,postbreak=]|#1|}
+\newcommand{\cleaninline}[1]{\lstinline[language=Clean,basicstyle=\tt,postbreak=]|#1|}
+\newcommand{\haskellinline}[1]{\lstinline[language=Haskell,style=haskell,basicstyle=\tt,postbreak=]|#1|}
+\newcommand{\haskelllhstexinline}[1]{\lstinline[language=Haskell,style=haskelllhstex,basicstyle=\tt,postbreak=]|#1|}
%For storing listings in footnotes
\newsavebox{\LstBox}
% Fix list of listings title
\my@chapter}
\makeatother
+\lstnewenvironment{lstPython}[1][]
+ {%
+ \lstset{language=Python, #1}
+ \renewcommand*{\lstlistingname}{Listing (\gls{PYTHON})}
+ }
+ {}
\lstnewenvironment{lstClean}[1][]
{%
\lstset{language=Clean, #1}
\usepackage[nodayofweek]{datetime} % Use a fixed document date
\urlstyle{same}
\usepackage{bookmark}
-\usepackage{cleveref} % Easy references
+\usepackage[noabbrev]{cleveref} % Easy references
\crefname{part}{movement}{movements}
-\crefname{lstlisting}{listing}{listing}
+\crefname{lstlisting}{listing}{listings}
% Glossaries and acronyms
\usepackage[acronym,nonumberlist]{glossaries}
\def\Glsentrytext#1{}%
\def\titlecap#1{}%
}
+\usepackage{glossary-mcols}
% Index
%\usepackage{makeidx}
\ifSubfilesClassLoaded{%
- \bibliography{../other,../self}
+ \bibliography{../other,../self,../tiot}
\printglossaries%
}{
%\setcounter{tocdepth}{1}
\tableofcontents
\todo{reduce tocdepth to 1 before finishing}
+\todo{to reduce the size: make listings font smaller}
\newpage%
% Dedication
\addcontentsline{toc}{part}{Appendix}
\subfile{appendix/clean_for_haskell_programmers}
+\subfile{appendix/mtask_aux}
\subfile{appendix/bytecode}
\backmatter%
\phantomsection{}%
\label{chp:bibliography}
\addcontentsline{toc}{chapter}{Bibliography}
-\bibliography{other,self}
+\bibliography{other,self,tiot}
% Summary
\subfile{backmatter/summary}
% Glossary
\addcontentsline{toc}{chapter}{Glossary}%
\label{chp:glossaries}
-\printglossaries%
-
-% Lists of
-\cleardoublepage{}
-\phantomsection{}%
-\label{chp:listsof...}
-\addcontentsline{toc}{chapter}{Lists of \ldots}
-\begingroup
-\let\clearpage\relax
-\let\cleardoublepage\relax
-\listoffigures%
+\printglossary%
+%\printglossary[type=\acronymtype,style=mcolindex]%
+\printglossary[type=\acronymtype]%
+
+%% Lists of
+%\cleardoublepage{}
+%\phantomsection{}%
+%\label{chp:listsof...}
+%\addcontentsline{toc}{chapter}{Lists of \ldots}
+%\begingroup
+%\let\clearpage\relax
+%\let\cleardoublepage\relax
+%\listoffigures%
%\listoftables%
%\listofalgorithms%
%\lstlistoflistings%
-\endgroup
+%\endgroup
% Index
%\addcontentsline{toc}{chapter}{Index}%
--- /dev/null
+CmdLine {
+ -v
+}
+VerbEnvir {
+ lstinline lstlisting algorithm code spec lstClean lstHaskell lstHaskellLhstex lstArduino lstPython
+}
+WipeArg {
+ \cinline:{}
+ \cleaninline:{}
+ \pythoninline:{}
+ \haskellinline:{}
+ \haskelllshtexinline:{}
+ \arduinoinline:{}
+ \texttt:{}
+ \url:{}
+ \only:{}
+ \orcid:{}
+}
+Silent {
+ \pause
+}
+MathEnvir {
+ code
+}
--- /dev/null
+<mxfile host="app.diagrams.net" modified="2021-08-26T08:38:16.149Z" agent="5.0 (X11)" etag="Dulvfis5CUlRJCdaxnkN" version="14.9.9" type="device"><diagram id="FaWps5j_e-cIahgQRTr2" name="Page-1">7V3bdqM2FP0aP8aLm7g8Jp7bQ9JxJ2ln+tRFDGPTEONiPIn79RUGYZCEkQkSMqFrVmNkW4azt47OTdJEnz2/fo7dzeou8vxwoine60T/MNE01VFs+Cdt2ectqmlkLcs48PK2Y8N98J+fNyp56y7w/G3lg0kUhUmwqTYuovXaXySVNjeOo5fqx35GYfVXN+7SJxruF25Itn4PvGSVtdpAObZ/8YPlCv2yquTvPLvow3nDduV60UupSf840WdxFCXZq+fXmR+m0kNyyb73qebd4sZif52wfOGH4n38zdrdguurP9ebPx3X2Px1paK7++WGu/yR89tN9kgGcbRbe37ajTLRb15WQeLfb9xF+u4LhB22rZLnEF6p8OU2iaOnQlZpy89onXxyn4Mw5cBt8OjHSbCGX74hnyB/qF/wI/5rqSl/os9+9Own8R5+JH/XMPP7z/lVSPvlCJaOuLQqAaWjL7o5QZZF30cZwhe5GM8RabNA/bV3nXITXq2jgyg8d7s6SFitSvN82flehdCk5EqSARTBoLbYD90k+FUdBjRh5b8wjwJ4J0dgMFxsTNzbaBcv/PxLZdZi/VgWON1R4sZLPyE6OkBXPHV7NA0CzevNJgwWUDbRGr5x6+79mAAYsjehDYtZFEbxEfWfQRhiTW4YLNfwcgFxhR3rN+lYgD8XXudvPAeel/4MdRxWRyrXgVfFV9fJcVfoljK9NF7DDhBAzWN/Cx9wRKo6gIy+kTIJpH7zk5cofhpBQiAZvQ8nixxOPlTYm3EwlXECFHNDLE72aG1Qho/SkbVBdMTZ2nBGNClodmU7Eh1xRlPVCDgfZnPY1d3vDw/wzzyOkuhx95PEOAyhf5tCBZ3GTdq4CKOd1+x88VR9qlkzyEqkKKzzMitwqXfnaemEfGff7if6NWzLBH2ISqSy9eMATjHb3BY0w3SaeoQTmLlMX82+V771/OBuny4DlILS8oBCekyknQDRWC9rp/OS7Lwg9hcH0FJ1F6ePVC/PIsKidCNcoFSFqzmkcGmy5RdaIJ0cQrYFOfdhAI2iWG8W8mNmPt0+Fg3u4ml5MKq+7pLwINzMmsvCc/A2+LLa1KuC1ymsNoQKnvRZvvuPafBvSwBwNEbVfnVDYZwi+lKcCqoYDW5iJL2KQhkjXYwaUslM0rhu5ifA5n93UfYBSAcAZk65Kfvul4e7W/R9eINZF9Vutxt3XcEL9XEA6mqbIZXOBZvYJ38B/oW/75Q6hL+T9Vn9HdhcPJL8VNFwTdc7VTQGVZeaq/f5ZTo3RMto7YYfj62YY3j8zG0UbXKx/uMnyT7PO7i7JML9VzdOkL29CN3tNlig5k9B2B6bzIY9NVZyzy6zUU9JitV4Z7bK3zbGaR5p+yFN6If5l3l3Y5l1BPNWKgr6R70jqD+gAfuLEnA5KzMj0jmgzdhiAyMagx06bAXiXKYC0UhbawTupKqVBDiVFr3KFJoX/OrCviMmg2++F2xbKGzYXLmlAfpQRdYbT5z25UMVj8DJMLiL1svow3nT9xBxt5txt4TizpKikEafl8Lrxw/BxspHoFh+pHcyNRwHNfx1aFBVEzV8eM1vNrval6/mfhxA6aaZrpYpq8ZZBEm5eRbRpJpF0H1z8x/2kDpFDHg4LkRDXGIWhaG/SCKJfQiipsTs24fQWXwImsKoUTYlQfqvQZLpEKDY+XWuQhQtvz5qkPRiX7rA9UdJJYGyQirUVc/KCGVqyspoM1/e/Dc3Pi2Cr97DH+r89+uve1QbIkkiEo9DGzqodsGaiTQBRm2AUZZzJlJniaa1JHJBvepMCJqoVwwAo0r/s8nfJ19Z504xfAUOxlcVoxkrXw0FJ75gvtISBV3z9UxVWfDVAhXCmoYpmLKnmNhs7smlYnVMM7Yu9jDxbJclmLLn1e6IpWyFsSfZ2mcmA6UHh0bNvrUpsqtloibN8JSEr+yeszPylQtfGazVs7zWSoUk3/JgrD6YsXAFn6s682AN8YaUwjwrVf1e++Q4F2X4s459xFFZxz7OqNZjHw+u8B775xW0twy5ME8vZZJXWT51Gj3cboIr3QVwBVFRr9GBF0dF8RY9u+7UVXmVpyxE7EonaqoyVcr/macJzpmXgCx771NFciCSbUhFJDx6azgtiWSihELBSFMsc4TkM9pMrrpaUYOZPpNhbtWlYiIYytwKOCYk3sZEuxciNqtEcJmMtfDFfG11Z9+MNWmMbZW7z1YnKSlJrrKqoPQte/NaX1/wlsoH7iUOtHKGTpZzTGYfJzezasEG8XtY3fQjpeCh5gHeElHiWgdhO1Ulj7J45WVnGjli+W3YQKvIrcBKkouF3ff+envEZ7srsFPLmO0ILjWV8cmDJJaPBShqVN6dCIhEsn4B1tuQpIA4nU4HAqOua1PQCKQqFMjGVTbdAbkeCozAkg1GFJHgG2LSuGeN4T3mhbc6urnSNQdzGE1JjeawKVucnlAleOE1u0FMdIWX+3A2ia3ztrqTteRBPHmtkbz9k1cTQV5rgOxlLecZ2cuRvbQcwBiN4BmNYIpDDCwUoVoKneZ9hSIsWgZjDEUwIGliQaW+QxFWfTx1DEXUR5RUdarJ5sTyCg8OOBah6aZ8OHIsvRp0MAJNSo0WsSVXbk7TSWXS1iTWbLIv0TbxMFZgiKcva2p5pC9P+tpCYsEDDEhYrLHgkb9c+UtGg+ff7gkKD3+PeGKjZFTO2LAIhN8e8WSoc/79PSKj4bsl944MQymvND4Lvtc0bXFTcfyVkNVNNi0aJKv4TIa1YYLFd7Hr7CytWZZC19k5NOPtdPC5XVAk35u+aXe7x9oQiORaPn1jVoTlUTBe2AAUqv2d+iKebkkTjKThOemJJQ3HKIc4b6/trkG1iDbXxStyLSoCSm012rnOH9C1qa3i7p/mVHvjfdiNQpsCR2JeHjF1e2p1xkylZ1KKKFE7jykyxNQuj5Sm3h0pgT01dLw34cwkgzKzdxkuI46w6jsooyqUc8XeZbwM95gkgIYh4sPpdLEO5Ak0MkqvWIRIhe5xqyoMWwSJ2hhd7OHxAJBFGIozJcswaICogBcgauNG+Y1RAJMWBTgZBHh3ug1oxhRtM1pkzMixqB7tjopZww180izoBPz7D/fbEfzjyCecbyT4HrE/cULGY10o75yYXV+xuEVXsTisGpl2Sp1Yc4RyyNQh552WgbvPqdSy/8MWeTOuHSCDp7xVykmp1KNSOUJDJrdmNdDIa9x3MWj6hIa6UzVDSOZSDgjGzliinXrH64DgU5uAlw8ch9MFefDopcgXS/PqtOUnIuXLcee1ttFE9o2UT5+sUAtXdzvPy7UeEGARQL39zvNYR/y2S6bK/70cCo4fD0RRBrwOtDt1Vk1J7pmTNUTZ4+fXaOJkv7vdGD9W2vb66cvfydVn4+Zv9Q8WG6KlIsaTK9XUCxc1Xd3KFbxdTZ+OKzEkf+Q6iAHghTu4gmXP/ODxbG6amspa2TY9lC9DThUb6zG3gnaDJdbtGS3tBsOZKkRv6LhMQZRkOWx5pKTslASdUZLMiAgmpIgDK86cuyUr2LgEQuJVk60JaRlT0yZqNcRSkmFdtLw5Z1MnUh1o/3oBKWeqPBkqWIeZcDYtYt8gxRaYb6a7UvVLF8Z0c5fRi6mpVbFXyXHIL+VIx55TqcGYba4Oe7J4EUm+R+w1bpbWEGIoJ3Vlozkm18mApkox67F6V2aLzCT6MiysL872mHphm4DJoeEqizM70GqGTRZQUbYw4lWQQWfGJW0qNkxapIuR0MGoJ2ihgqmpi2TG5WxSNlBeAEAYwDLwgteJCONcctZCA3MKzEZyiJ1LBB6xMM4lNWlnaGLYx3MXVfnUBy2WNU4rAiliWVNbJC/gZRylWB09Gvicq7vI89NP/A8=</diagram></mxfile>
\ No newline at end of file
--- /dev/null
+import io
+import matplotlib.pyplot as plt
+import pandas as pd
+
+components = [ 'Sensor Interface',
+ 'Sensor Node',
+ 'Manage Nodes',
+ 'Web Interface',
+ 'Database Interface',
+ 'Communication'
+ ]
+
+plt.rcParams["font.family"] = "serif"
+plt.rcParams['mathtext.fontset'] = 'custom'
+plt.rcParams['mathtext.rm'] = 'Libertine'
+plt.rcParams['mathtext.it'] = 'Libertine:italic'
+plt.rcParams['mathtext.bf'] = 'Libertine:bold'
+
+CB_color_cycle = ['#377eb8', '#ff7f00', '#4daf4a',
+ '#f781bf', '#a65628', '#984ea3',
+ '#999999', '#e41a1c', '#dede00']
+
+#data = '''PWS,PRS,CWS,CRS
+#9,10,7,7
+#32,32,5,3
+#14,13,21,19
+#10,10,17,18
+#19,18,47,50
+#17,17,3,3'''
+data = '''PWS,PRS,CWS,CRS
+9.252669039145907,9.895833333333333,6.626506024096386,7.096774193548387
+31.67259786476868,31.77083333333333,5.421686746987952,2.5806451612903226
+13.523131672597866,13.194444444444445,21.084337349397592,19.35483870967742
+9.9644128113879,9.722222222222222,16.86746987951807,18.064516129032257
+18.861209964412812,18.40277777777778,46.987951807228917,50.32258064516129
+16.725978647686832,17.01388888888889,3.0120481927710843,2.5806451612903226
+'''
+
+# convert CSV literal string into pandas data frame
+
+df = pd.read_csv(io.StringIO(data), sep=",", header=0)
+df.index = components
+print(df)
+
+fig, ax = plt.subplots()
+
+ax.bar(df.columns, df.loc[components[-1]], label=components[-1])
+baseline = df.loc[components[-1]]
+for i in range(len(components)-2, -1, -1):
+ ax.bar(df.columns, df.loc[components[i]], label=components[i],
+ bottom = baseline, color=CB_color_cycle[i])
+ baseline += df.loc[components[i]]
+#y_offset=-15
+y_offset=-1.2
+for bar in ax.patches:
+ ax.text(
+ # Put the text in the middle of each bar. get_x returns the start
+ # so we add half the width to get to the middle.
+ bar.get_x() + bar.get_width() / 2,
+ # Vertically, add the height of the bar to the start of the bar,
+ # along with the offset.
+ bar.get_height() /2 + bar.get_y() + y_offset,
+# bar.get_height() + bar.get_y() + y_offset,
+ # This is actual value we'll show.
+ round(bar.get_height()),
+ # Center the labels and style them a bit.
+ ha='center',
+ color='black',
+ weight='bold',
+ size=8
+ )
+
+#ax.bar(labels, women_means, width, yerr=women_std, bottom=men_means,
+# label='Women')
+
+ax.set_ylabel('% coverage')
+#ax.set_title('Source code coverage by component')
+
+box = ax.get_position()
+ax.set_position([box.x0, box.y0, box.width * 0.7, box.height])
+
+handles, labels = plt.gca().get_legend_handles_labels()
+##order = list(range(len(components)))
+order = list(range(len(components)-1, -1, -1))
+plt.legend([handles[idx] for idx in order],[labels[idx] for idx in order], loc='center left', bbox_to_anchor=(1, 0.5))
+
+##ax.legend()
+
+plt.savefig('bar_chart.pdf')
+##plt.show()
}{}
\mychapter{chp:smart_campus}{Smart campus application}
-IOT2020/TIOT papers
+%\title{Could Tierless Languages Reduce IoT Development Grief?}
+
+\begin{chapterabstract}
+ \Gls{IOT} software is notoriously complex, conventionally comprising multiple tiers.
+ The developer must use multiple programming languages and ensure that the components interoperate correctly. A novel alternative is to use a single \emph{tierless} language with a compiler that generates the code for each component and ensures their correct interoperation.
+
+ We report a systematic comparative evaluation of two tierless language technologies for \gls{IOT} stacks: one for resource-rich sensor nodes (\gls{CLEAN} with \gls{ITASK}), and one for resource-constrained sensor nodes (\gls{CLEAN} with \gls{ITASK} and \gls{MTASK}).
+ The evaluation is based on four implementations of a typical smart campus application: two tierless and two \gls{PYTHON}-based tiered.
+ %, with two targeting microcontrollers and two targeting supersensors.
+ \begin{enumerate*}
+ \item We show that tierless languages have the potential to significantly reduce the development effort for \gls{IOT} systems, requiring 70\% less code than the tiered implementations. Careful analysis attributes this code reduction to reduced interoperation (e.g.\ two \glspl{EDSL} and one paradigm versus seven languages and two paradigms), automatically generated distributed communication, and powerful \gls{IOT} programming abstractions.
+ \item We show that tierless languages have the potential to significantly improve the reliability of \gls{IOT} systems, describing how \gls{CLEAN}\slash\gls{ITASK}/\gls{MTASK} maintains type safety, provides higher order failure management, and simplifies maintainability.
+ \item We report the first comparison of a tierless \gls{IOT} codebase for resource-rich sensor nodes with one for resource-constrained sensor nodes. The comparison shows that they have similar code size (within 7\%), and functional structure.
+ \item We present the first comparison of two tierless \gls{IOT} languages, one for resource-rich sensor nodes, and the other for resource-constrained sensor nodes.
+ \end{enumerate*}
+\end{chapterabstract}
+
+\section{Introduction}%
+\label{sec_t4t:Intro}
+
+Conventional \gls{IOT} software stacks are notoriously complex and pose very significant software development, reliability, and maintenance challenges. \Gls{IOT} software architectures typically comprise multiple components organised in four or more tiers or layers~\cite{sethi2017internet,Ravulavaru18,Alphonsa20}. This is due to the highly distributed nature of typical \gls{IOT} applications that must read sensor data from end points (the \emph{perception} layer), aggregate and select the data and communicate over a network (the \emph{network} layer), store the data in a database and analyse it (the \emph{application} layer) and display views of the data, commonly on web pages (the \emph{presentation} layer).
+
+Conventional \gls{IOT} software architectures require the development of separate programs in various programming languages for each of the components/tiers in the stack. This is modular, but a significant burden for developers, and some key challenges are as follows.
+\begin{enumerate*}
+ \item Interoperating components in multiple languages and paradigms increases the developer's cognitive load who must simultaneously think in multiple languages and paradigms, i.e.\ manage significant semantic friction.
+ \item The developer must correctly interoperate the components, e.g.\ adhere to the \gls{API} or communication protocols between components.
+ \item To ensure correctness the developer must maintain type safety across a range of very different languages and diverse type systems.
+ \item The developer must deal with the potentially diverse failure modes of each component, and of component interoperations.
+\end{enumerate*}
+
+A radical alternative development paradigm uses a single \emph{tierless} language that synthesizes all components/tiers in the software stack. There are established \emph{tierless} languages for web stacks, e.g.\ Links~\cite{cooper2006links} or Hop~\cite{serrano2006hop}.
+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~\cite{troyer_building_2018} and \gls{CLEAN} with \gls{ITASK}\slash\gls{MTASK}~\cite{lubbers_interpreting_2019}.
+
+\Gls{IOT} sensor nodes may be microcontrollers 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?
+
+
+This paper reports a systematic comparative evaluation of two tierless language technologies for \gls{IOT} stacks: one targeting resource-constrained microcontrollers, and the other resource-rich supersensors. The basis of the comparison is four implementations of a typical smart campus \gls{IOT} stack~\cite{hentschel_supersensors:_2016}. Two implementations are conventional tiered \gls{PYTHON}-based stacks: \gls{PRS} and \gls{PWS}. The other two implementations are tierless: \gls{CRS} and \gls{CWS}. Our work makes the following research contributions, and the key results are summarised, discussed, and quantified in \cref{sec_t4t:Conclusion}.
+
+\begin{description}
+ \item[C1] We show that \emph{tierless languages have the potential to significantly reduce the development effort for \gls{IOT} systems}.
+ We systematically compare code size (\gls{SLOC}) of the four smart campus implementations as a measure of development effort and maintainability~\cite{alpernaswonderful,rosenberg1997some}.
+ The tierless implementations require 70\% less code than the tiered implementations. We analyse the codebases to attribute the code reduction to three factors.
+ \begin{enumerate*}
+ \item Tierless languages benefit from reduced interoperation, requiring far fewer languages, paradigms and source code files e.g.\ \gls{CWS} uses two languages, one paradigm and three source code files where \gls{PWS} uses seven languages, two paradigms and 35 source code files
+ %\jscomment{check out \url{https://editorsmanual.com/articles/numerals-vs-words-for-numbers/} - do we agree with this?}
+ (\cref{table_t4t:multi,table_t4t:languages,table_t4t:paradigms}).
+ \item Tierless languages benefit from automatically synthesized, and hence correct, communication between components that may be distributed.
+ \item Tierless languages benefit from high-level programming abstractions like compositional and higher-order task combinators (\cref{sec_t4t:ProgrammingComparison}).
+ \end{enumerate*}
+
+ \item[C2] We show that \emph{tierless languages have the potential to significantly improve the reliability of \gls{IOT} systems}. We demonstrate how tierless languages preserve type safety, improve maintainability and provide high-level failure management. For example, we illustrate a loss of type safety in \gls{PRS}. We also critique current tool and community support (\cref{sec_t4t:Discussion}).
+
+ \item[C3] We report \emph{the first comparison of a tierless \gls{IOT} codebase for resource-rich sensor nodes with one for resource-constrained sensor nodes}. The tierless smart campus implementations have a very similar code size (within 7\%), as do the tiered implementations. This suggests that the development and maintenance effort of simple tierless \gls{IOT} systems for resource-constrained and for resource-rich sensor nodes is similar, as it is for tiered technologies. The percentages of code required to implement each \gls{IOT} functionality in the tierless \gls{CLEAN} implementations is very similar, as it is in the tiered \gls{PYTHON} implementations. This suggests that the code for resource-constrained and resource-rich sensor nodes is broadly similar in tierless technologies, as in tiered technologies (\cref{sec_t4t:resourcerich})
+
+ \item[C4] \emph{We present 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}).}
+ We show that the bare metal execution environment enforces some restrictions on \gls{MTASK} although they remain high level. Moreover, the environment conveys some advantages, e.g.\ better control over timing (\cref{sec_t4t:ComparingTierless}).
+\end{description}
+
+The current work extends~\cite{lubbers_tiered_2020} as follows. Contributions C3 and C4 are entirely new, and C1 is enhanced by being based on the analysis of four rather than two languages and implementations.
+
+\section{Background and related work}%
+\label{sec_t4t:Background}
+
+\subsection{\texorpdfstring{\Acrlong{UOG}}{University of Glasgow} smart campus}%
+\label{sec_t4t:UoGSmartCampus}
+% Jeremy
+The \gls{UOG} is partway through a ten-year campus
+upgrade programme, and a key goal is to embed pervasive sensing infrastructure into
+the new physical fabric to form a \emph{smart campus} environment.
+As a prototyping exercise, we use modest commodity
+sensor nodes (i.e.\ Raspberry Pis) and low-cost, low-precision sensors
+for indoor environmental monitoring.
+
+We have deployed sensor nodes into 12 rooms in two buildings. The \gls{IOT} system has an online data store, providing live
+access to sensor data through a RESTful \gls{API}.
+This allows campus stakeholders to add functionality at a business layer above the layers that we consider here. To date,
+simple apps have been developed including room temperature
+monitors and campus utilization maps~\cite{hentschel_supersensors:_2016}.
+A longitudinal study of sensor accuracy has also been
+conducted~\cite{harth_predictive_2018}.
+
+\subsection{\texorpdfstring{\Gls{IOT}}{IoT} applications}%
+\label{sec_t4t:Stacks}
+
+Web applications are necessarily complex distributed systems, with client browsers interacting with a remote webserver and data store. Typical \gls{IOT} applications
+are even more complex as they combine a web application with a second distributed system of sensor and actuator nodes that collect and aggregate data, operate on it, and communicate with the server.
+
+Both web and \gls{IOT} applications are commonly structured into tiers, e.g.\ the classical four-tier Linux, Apache, MySQL and PHP (LAMP) stack.
+\Gls{IOT} stacks typically have more tiers than webapps, with the number depending on the complexity of the application~\cite{sethi2017internet}. While other tiers, like the business layer~\cite{muccini2018iot} may be added above them, the focus of our study is on programming the lower four tiers of the \gls{PRS}, \gls{CRS}, \gls{PWS} and \gls{CWS} stacks, as illustrated in \cref{fig_t4t:iot_arch}.
+
+\begin{landscape}
+ \begin{figure}[ht]
+ \includegraphics[width=\linewidth]{arch}
+ \caption{%
+ \gls{PRS} and \gls{PWS} (left) together with \gls{CRS} and \gls{PRS} (right) mapped to the four-tier \gls{IOT} architecture.
+ Every box is the diagram denotes a source file or base.
+ Bold blue text describes the language or technology used in that source.
+ The network and perception layer are unique to the specific implementation, where the application and presentation layers are shared between implementations.
+ }%
+ \label{fig_t4t:iot_arch}
+ \end{figure}
+\end{landscape}
+%
+\begin{enumerate}
+
+ \item Perception Layer {--} collects the data, interacts with the environment, and consists of devices using light, sound, motion, air quality and temperature sensors.
+ \item Network Layer {--} replays the communication messages between the sensor nodes and the server through protocols such as \gls{MQTT}.
+
+ \item Application Layer {--} acts as the interface between the presentation layer and the perception layer, storing and processing the data.
+
+ \item Presentation Layer {--} utilises web components as the interface between the human and devices where application services are provided.
+
+\end{enumerate}
+
+
+\subsection{The benefits and challenges of developing tiered \texorpdfstring{\gls{IOT}}{IoT} stacks}
+
+Using multiple tiers to
+structure complex software is a common software engineering practice that provides significant architectural benefits for \gls{IOT} and other software. The tiered \gls{PYTHON} \gls{PRS} and \gls{PWS} stacks exhibit these benefits.
+\begin{enumerate}
+
+ \item Modularity: tiers allow a system to be structured as a set of components with clearly defined functionality. They can be implemented independently, and may be interchanged with other components that have similar functionality~\cite{maccormack2007impact}. In \gls{PRS} and \gls{PWS}, for example, a different NoSQL DBMS could relatively easily be substituted for {MongoDB}
+
+ \item Abstraction: the hierarchical composition of components in the stack abstracts the view of the system as a whole. Enough detail is provided to understand the roles of each layer and how the components relate to one another~\cite{belle2013layered}. \Cref{fig_t4t:iot_arch} illustrates the abstraction of \gls{PRS} and \gls{PWS} into four tiers.
+
+ \item Cohesion: well-defined boundaries ensure each tier contains functionality directly related to the task of the component~\cite{lee2001component}. The tiers in \gls{PRS} and \gls{PWS} contain all the functionality associated with perception, networking, application and presentation respectively.
+
+\end{enumerate}
+
+However, a tiered architecture poses significant challenges for developers of \gls{IOT} and other software. The tiered \gls{PYTHON} \gls{PRS} and \gls{PWS} stacks exhibit these challenges, and we analyse these in detail later in the paper.
+
+\begin{enumerate}
+
+ \item Polyglot Development {--} the developer must be fluent in all the languages and components in the stack, known as being a full stack developer for webapps~\cite{mazzei2018full}. That is, the developer must correctly use multiple languages that have different paradigms, i.e.\ manage significant \emph{semantic friction}~\cite{ireland2009classification}. For example the \gls{PWS} developer must integrate components written in seven languages with two paradigms (\cref{sec_t4t:interoperation}).
+
+ \item Correct Interoperation {--} the developer must adhere to the \gls{API} or communication protocols between components. \Cref{sec_t4t:codesize,sec_t4t:resourcerich} show that communication requires some 17\% of \gls{PRS} and \gls{PWS} code, so around 100 \gls{SLOC}. \Cref{sec_t4t:Communication} discusses the complexity of writing this distributed communication code.
+
+ \item Maintaining Type Safety {--} is a key element of the semantic friction encountered in multi-language stacks, and crucial for correctness. The developer must maintain type safety across a range of very different languages and diverse type systems, with minimal tool support. We show an example where \gls{PRS} loses type safety over the network layer (\Cref{sec_t4t:typesafety}).
+
+
+ \item Managing multiple failure modes {--} different components may have different failure modes, and these must be coordinated. \Cref{sec_t4t:NetworkManagement} outlines how \gls{PRS} and \gls{PWS} use heartbeats to manage failures.
+\end{enumerate}
+
+
+Beyond \gls{PRS} and \gls{PWS} the challenges of tiered polyglot software development are evidenced in real world studies. As recent examples, a study of GitHub open source projects found an average of five different languages in each project, with many using tiered architectures~\cite{mayer2017multi}.
+An earlier empirical study of GitHub shows that using more languages to implement a project has a significant effect on project quality, since it increases defects~\cite{kochhar2016large}.
+A study of \gls{IOT} stack developers found that interoperation poses a real challenge, that microservices blur the abstraction between tiers, and that both testing and scaling \gls{IOT} applications to more devices are hard~\cite{motta2018challenges}.
+
+One way of minimising the challenges of developing tiered polyglot \gls{IOT} software is to standardise and reuse components. This approach has been hugely successful for web stacks, e.g.\ browser standards. The W3C
+Web of Things aims to facilitate re-use by providing standardised metadata and other re-usable technological \gls{IOT} building blocks~\cite{guinard_building_2016}. However, the Web of Things has yet to gain widespread adoption. Moreover, as it is based on web technology, it requires the \emph{thing} to run a web server, significantly increasing the hardware requirements.
+
+\section{Tierless languages}%
+\label{sec_t4t:TiredvsTierless}
+
+A radical approach to overcoming the challenges raised by tiered distributed software is to use a tierless programming language that eliminates the semantic friction between tiers by generating code for all tiers, and all communication between tiers, from a single program.
+%\adriancomment{Also referred to as multi-tier programming, tierless language applications usually utilise a single language, paradigm and type system, and the entire system is simultaneously checked by the compiler~\cite{weisenburger2020survey}.}
+Typically a tierless program uses a single language, paradigm and type system, and the entire distributed system is simultaneously checked by the compiler.
+
+There is intense interest in developing tierless, or multitier, language technologies with a number of research languages developed over the last fifteen years, e.g.\ \cite{cooper2006links, serrano2006hop, troyer_building_2018, 10.1145/2775050.2633367}. These languages demonstrate the
+advantages of the paradigm, including less development effort, better maintainability, and sound semantics of distributed execution. At the same time a number of industrial technologies incorporate tierless concepts, e.g.\ \cite{balat2006ocsigen, bjornson2010composing, strack2015getting}. These languages demonstrate the benefits of the paradigm in practice. Some tierless languages use (embedded) \glspl{DSL} to specify parts of the multi-tier software.
+
+Tierless languages have been developed for a range of distributed paradigms, including web applications, client-server applications, mobile applications, and generic distributed systems. A recent and substantial survey of these tierless technologies is available~\cite{weisenburger2020survey}. Here we provide a brief introduction to tierless languages with a focus on \gls{IOT} software.
+
+\subsection{Tierless web languages}
+% Standalone DSLs
+There are established tierless languages for web development, both standalone languages and \glspl{DSL} embedded in a host language.
+Example standalone tierless web languages are Links~\cite{cooper2006links} and Hop~\cite{serrano2006hop}.
+From a single declarative program the client, server and database code is simultaneously checked by the compiler, and compiled to the required component languages. For example, Links compiles to HTML and JavaScript for the client side and to SQL on the server-side to interact with the database system.
+
+An example tierless web framework that uses a \gls{DSL} is Haste~\cite{10.1145/2775050.2633367}, that embeds the \gls{DSL} in \gls{HASKELL}. Haste programs are compiled multiple times: the server code is generated by the standard \gls{GHC} \gls{HASKELL} compiler~\cite{hall1993glasgow}; Javascript for the client is generated by a custom \gls{GHC} compiler backend. The design leverages \gls{HASKELL}'s high-level programming abstractions and strong typing, and benefits from \gls{GHC}: a mature and sophisticated compiler.
+
+
+\subsection{Tierless \texorpdfstring{\gls{IOT}}{IoT} languages}
+The use of tierless languages in \gls{IOT} applications is both more recent and less common than for web applications.
+Tierless \gls{IOT} programming may extend tierless web programming by adding network and perception layers.
+The presentation layer of a tierless \gls{IOT} language, like tierless web languages, benefits from almost invariably executing in a standard browser. The perception layer faces greater challenges, often executing on one of a set of slow and resource-constrained microcontrollers. Hence, tierless \gls{IOT} languages typically compile the perception layer to either \gls{C}\slash\gls{CPP} (the lingua franca of microcontrollers), or to some intermediate representation to be interpreted.
+
+\subsubsection{\texorpdfstring{\Glspl{DSL}}{DSLs} for microcontrollers}
+Many \glspl{DSL} provide high-level programming for microcontrollers, for example providing strong typing and memory safety.
+For example Copilot~\cite{hess_arduino-copilot_2020}
+and Ivory~\cite{elliott_guilt_2015} are imperative \glspl{DSL} embedded in a functional language that compile to \gls{C}\slash\gls{CPP}. In contrast to \gls{CLEAN}/\gls{ITASK}/\gls{MTASK} such \glspl{DSL} are not tierless \gls{IOT} languages as they have no automatic integration with the server, i.e.\ with the application and presentation layers.
+
+
+\subsubsection{\texorpdfstring{\Gls{FRP}}{Functional reactive programming}}
+\Gls{FRP} is a declarative paradigm often used for implementing the perception layer of an \gls{IOT} stack.
+Examples include mfrp~\cite{sawada_emfrp:_2016}, CFRP~\cite{suzuki_cfrp_2017}, XFRP~\cite{10.1145/3281366.3281370}, Juniper~\cite{helbling_juniper:_2016}, Hailstorm~\cite{sarkar_hailstorm_2020}, and Haski~\cite{valliappan_towards_2020}.
+None of these languages are tierless \gls{IOT} languages as they have no automatic integration with the server.
+
+Potato goes beyond other \gls{FRP} languages to provide a tierless \gls{FRP} \gls{IOT} language for resource rich sensor nodes~\cite{troyer_building_2018}. It does so using the Erlang programming language and sophisticated virtual machine.
+
+TOP allows for more complex collaboration patterns than \gls{FRP}~\cite{wang_maintaining_2018}, and in consequence is unable to provide the strong guarantees on memory usage available in a restricted variant of \gls{FRP} such as arrowized \gls{FRP}~\cite{nilsson_functional_2002}.
+
+\subsubsection{Erlang/Elixir \texorpdfstring{\gls{IOT}}{IoT} systems}
+A number of production \gls{IOT} systems are engineered in Erlang or Elixir, and many are mostly tierless.
+That is the perception, network and application layers are sets of distributed Erlang processes, although the presentation layer typically uses some conventional web technology.
+A resource-rich sensor node may support many Erlang processes on an Erlang VM, or low level code (typically \gls{C}\slash\gls{CPP}) on a resource-constrained microcontroller can emulate an Erlang process.
+Only a small fraction of these systems are described in the academic literature, example exceptions are~\cite{sivieri2012drop,shibanai_distributed_2018}, with many described only in grey literature or not at all.
+
+\subsection{Characteristics of tierless \texorpdfstring{\gls{IOT}}{IoT} languages}%
+\label{sec_t4t:characteristics}
+
+This study compares a pair of tierless \gls{IOT} languages with conventional tiered \gls{PYTHON} \gls{IOT} software. \gls{CLEAN}\slash\gls{ITASK} and \gls{CLEAN}/\gls{ITASK}/\gls{MTASK} represent a specific set of tierless language design decisions, however many alternative designs are available. Crucially the limitations of the tierless \gls{CLEAN} languages, e.g.\ that they currently provide limited security, should not be seen as limitations of tierless technologies in general. This section briefly outlines key design decisions for tierless \gls{IOT} languages, discusses alternative designs, and describes the \gls{CLEAN} designs. The \gls{CLEAN} designs are illustrated in the examples in the following section.
+
+\subsubsection{Program splitting}
+
+A key challenge for an automatically segmented tierless language is to determine which parts of the program correspond to a particular tier and hence should be executed by a specific component on a specific host, so-called tier splitting.
+For example a tierless web language must identify client code to ship to browsers, database code to execute in the DBMS, and application code to run on the server. Some tierless languages split programs using types, others use syntactic markers, e.g.\ pragmas like \cleaninline{server} or \cleaninline{client}, to split the program~\cite{cooper2006links,10.1145/2775050.2633367}. It may be possible to infer the splitting between tiers, relieving the developers from the need specify it, as illustrated for Javascript as a tierless web language~\cite{10.1145/2661136.2661146}.
+
+In \gls{CLEAN}\slash\gls{ITASK}/\gls{MTASK} and \gls{CLEAN}/\gls{ITASK} tier splitting is specified by functions, and hence is a first-class language construct.
+For example in \gls{CLEAN}\slash\gls{ITASK} the \cleaninline{asyncTask} function identifies a task for execution on a remote device and \cleaninline{liftmTask} executes the given task on an \gls{IOT} device. The tier splitting functions are illustrated in examples in the next section, e.g.\ on \cref{lst_t4t:itaskTempFull:startdevtask} in \cref{lst_t4t:itaskTempFull} and \cref{lst_t4t:mtaskTemp:liftmtask} in \cref{lst_t4t:mtaskTemp}.
+Specifying splitting as functions means that new splitting functions can be composed, and that splitting is under program control, e.g.\ during execution a program can decide to run a task locally or remotely.
+
+\subsubsection{Communication}\label{ssec_t4t:communication}
+
+Tierless languages may adopt a range of communication paradigms for communicating between components. Different tierless languages specify communication in different ways~\cite{weisenburger2020survey}. Remote procedures are the most common communication mechanism: a procedure/function executing on a remote host/machine is called as if it was local. The communication of the arguments to, and the results from, the remote procedure is automatically provided by the language implementation. Other mechanisms include explicit message passing between components; publish/subscribe where components subscribe to topics of interest from other components; reactive programming defines event streams between remote components; finally shared state makes changes in a shared and potentially remote data structure visible to components.
+
+\Gls{CLEAN}\slash\gls{ITASK}/\gls{MTASK} and \gls{CLEAN}/\gls{ITASK} communicate using a combination of remote task invocation, similar to remote procedures, and shared state through \glspl{SDS}.
+\Cref{lst_t4t:itaskTempFull} illustrates: \cref{lst_t4t:itaskTempFull:startdevtask} shows a server task launching a remote task, \cleaninline{devTask}, on to a sensor node; and \cref{lst_t4t:itaskTempFull:remoteShare} shows the sharing of the remote \cleaninline{latestTemp} \gls{SDS}.
+%\mlcomment{I think this is fine}
+
+\subsubsection{Placement}
+
+In many \gls{IOT} systems the sensor nodes are microcontrollers that are programmed by writing the program to flash memory. This means that without extra effort, physical access to the microcontroller is needed to change the program making updates challenging.
+Hence, most \gls{IOT} systems compile sensor node code directly for the target architecture or via an existing language such as \gls{C}\slash\gls{CPP}.
+
+Techniques such as over-the-air programming and interpreters allow microcontrollers to be dynamically provisioned, increasing their maintainability and resilience.
+For example Baccelli et al.\ provide a single language \gls{IOT} system based on the RIOT \gls{OS} that allows runtime deployment of code snippets called containers~\cite{baccelli_reprogramming_2018}.
+Both client and server are written in JavaScript. However, there is no integration between the client and the server other than that they are programmed from a single source.
+Mat\`e is an example of an early tierless sensor network framework where devices are provided with a virtual machine using TinyOS for dynamic provisioning~\cite{levis_mate_2002}.
+
+Placement specifies how data and computations in a tierless program are assigned to the
+devices/hosts in the distributed system. Different tierless languages specify placement in different ways, e.g.\ code annotations or configuration files, and at different granularities, e.g.\ per function or per class~\cite{weisenburger2020survey}.
+
+\Gls{CLEAN}\slash\gls{ITASK}/\gls{MTASK} and \gls{CLEAN}/\gls{ITASK} both use dynamic task placement, similar to dynamic function placement.
+In \gls{CLEAN}\slash\gls{ITASK}/\gls{MTASK} sensor nodes are programmed once with the \gls{MTASK} \gls{RTS}, and possibly some precompiled tasks.
+Thereafter a sensor node can dynamically receive \gls{MTASK} programs, compiled at runtime by the server.
+In \gls{CLEAN}\slash\gls{ITASK} the sensor node runs an \gls{ITASK} server that recieves and executes code from the (\gls{IOT}) server~\cite{oortgiese_distributed_2017}.
+%The \gls{ITASK} server decides what code to execute depending on the serialised execution graph that the server sends~\cite{oortgiese_distributed_2017}.
+Placement happens automatically as part of the first-class splitting constructs outlined in \cref{ssec_t4t:communication}, so \cref{lst_t4t:mtaskTemp:liftmtask} in \cref{lst_t4t:mtaskTemp} places \cleaninline{devTask} onto the \cleaninline{dev} sensor node.
+
+\subsubsection{Security}
+
+Security is a major issue and a considerable challenge for many \gls{IOT} systems~\cite{10.1145/3437537}. There are potentially security issues at each layer in an \gls{IOT} application (\cref{fig_t4t:iot_arch}). The security issues and defence mechanisms at the application and presentation layers are relatively standard, e.g.\ defending against SQL injection attacks. The security issues at the network and perception layers are more challenging. Resource-rich sensor nodes can adopt some standard security measures like encrypting messages, and regularly applying software patches to the operating system. However microcontrollers often lack the computational resources for encryption, and it is hard to patch their system software because the program is often stored in flash memory. In consequence there are infamous examples of \gls{IOT} systems being hijacked to create botnets~\cite{203628,herwig_measurement_2019}.
+
+Securing the entire stack in a conventional tiered \gls{IOT} application is particularly challenging as the stack is implemented in a collection of programming languages with low level programming and communication abstractions. In such polyglot distributed systems it is hard to determine, and hence secure, the flow of data between components. In consequence a small mistake may have severe security implications.
+
+A number of characteristics of tierless languages help to improve security. Communication and placement vulnerabilities are minimised as communication and placement are automatically generated and checked by the compiler. So injection attacks and the exploitation of communication/placement protocol bugs are less likely. Vulnerabilities introduced by mismatched types are avoided as the entire system is type checked. Moreover, tierless languages can exploit language level security techniques. For example languages like Jif/split~\cite{zdancewic2002secure} and Swift~\cite{chong2007secure} place components to protect the security of data. Another example are programming language technologies for controlling information flow, and these can be used to improve security. For example Haski uses them to improve the security of \gls{IOT} systems~\cite{valliappan_towards_2020}.
+
+However many tierless languages have yet to provide a comprehensive set of security technologies, despite its importance in domains like web and \gls{IOT} applications. For example Erlang and many Erlang-based systems~\cite{shibanai_distributed_2018,sivieri2012drop}, lack important security measures. Indeed security is not covered in a recent, otherwise comprehensive, survey of tierless technologies~\cite{weisenburger2020survey}.
+
+\Gls{CLEAN}\slash\gls{ITASK} and \gls{CLEAN}/\gls{ITASK}/\gls{MTASK} are typical in this respect: little effort has yet been expended on improving their security. Of course as tierless languages they benefit from static type safety and automatically generated communication and placement. Some preliminary work shows that, as the communication between layers is protocol agnostic, more secure alternatives can be used. One example is to run the \gls{ITASK} server behind a reverse proxy implementing TLS/SSL encryption~\cite{wijkhuizen_security_2018}. A second is to add integrity checks or even encryption to the communication protocol for resource-rich sensor nodes~\cite{boer_de_secure_2020}.
+
+\section{Task-oriented and \texorpdfstring{\gls{IOT}}{IoT} programming in \texorpdfstring{\gls{CLEAN}}{Clean}}
+
+To make this paper self-contained we provide a concise overview of \gls{CLEAN}, \gls{TOP}, and \gls{IOT} programming in \gls{ITASK} and \gls{MTASK}. The minor innovations reported here are the interface to the \gls{IOT} sensors, and the \gls{CLEAN} port for the Raspberry Pi.
+
+\Gls{CLEAN} is a statically typed functional programming language similar to \gls{HASKELL}: both languages are pure and non-strict~\cite{achten_clean_2007}.
+A key difference is how state is handled: \gls{HASKELL} typically embeds stateful actions in the \haskellinline{IO} Monad~\cite{peyton_jones_imperative_1993,wiki:IO}.
+In contrast, \gls{CLEAN} has a uniqueness type system to ensure the single-threaded use of stateful objects like files and windows~\cite{barendsen_smetsers_1996}.
+Both \gls{CLEAN} and \gls{HASKELL} support fairly similar models of generic programming~\cite{ComparingGenericProgramming}, enabling functions to work on many types. As we shall see generic programming is heavily used in task-oriented programming~\cite{GenericProgrammingExtensionForClean,HinzeGenericFunctionalProgramming}, for example to construct web editors and communication protocols that work for any user-defined datatype.
+
+\subsection{\texorpdfstring{\Acrlong{TOP}}{Task-oriented programming}}
+
+\Gls{TOP} is a declarative programming paradigm for constructing interactive distributed systems~\cite{plasmeijer_task-oriented_2012}.
+Tasks are the basic blocks of \gls{TOP} and represent work that needs to be done in the broadest sense.
+Examples of typical tasks range from allowing a user to complete a form, controlling peripherals, moderating other tasks, or monitoring a database.
+From a single declarative description of tasks all of the required software components are generated.
+This may include web servers, client code for browsers or \gls{IOT} devices, and for their interoperation.
+That is, from a single \gls{TOP} program the language implementation automatically generates an \emph{integrated distributed system}.
+Application areas range from simple web forms or blinking \glspl{LED} to multi-user distributed collaboration between people and machines~\cite{oortgiese_distributed_2017}.
+
+
+\Gls{TOP} adds three concepts: tasks, task combinators, and \glspl{SDS}. Example basic tasks are web editors for user-defined datatypes, reading some \gls{IOT} sensor, or controlling peripherals like a servo motor.
+Task combinators compose tasks into more advanced tasks, either in parallel or sequential and allow task values to be observed by other tasks.
+As tasks can be returned as the result of a function, recursion can be freely used, e.g.\ to express the repetition of tasks.
+There are also standard combinators for common patterns.
+Tasks can exchange information via \glspl{SDS}~\cite{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
+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~\cite{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}.
+
+Interaction with a device like the DHT sensor using a protocol like 1-Wire or gls{I2C} is abstracted into a library. So the \cleaninline{readTempTask} task starts by creating a \cleaninline{dht} sensor object (\cref{lst_t4t:itaskTemp:dhtDef}) thereafter \cleaninline{repeatEvery} executes a task at the specified \cleaninline{interval}. This task reads the temperature from the \cleaninline{dht} sensor, and with a sequential composition combinator \cleaninline{>>~} passes the \cleaninline{temp} value to \cleaninline{viewInformation} that displays it on the web page (\cref{lst_t4t:itaskTemp:viewInformation}).
+The tuning combinator \cleaninline{<<@} adds a label to the web editor displaying the temperature. Crucially, the \gls{ITASK} implementation transparently ships parts of the code for the web-interface to be executed in the browser, and \cref{fig_t4t:itaskTempSimple} shows the UML deployment diagram.
+
+\begin{lstClean}[%
+ numbers=left,
+ caption={SimpleTempSensor: a \gls{CLEAN}\slash\gls{ITASK} program to read a local room temperature sensor and display it on a web page},
+ label={lst_t4t:itaskTemp}]
+module simpleTempSensor
+
+import iTasks
+
+Start :: *World -> *World [+\label{lst_t4t:itaskTemp:systemfro}+]
+Start world = doTasks readTempTask world [+\label{lst_t4t:itaskTemp:systemto}+]
+
+readTempTask :: Task Real
+readTempTask =
+ withDHT IIO_TempID \dht -> [+\label{lst_t4t:itaskTemp:dhtDef}+]
+ repeatEvery interval ( [+\label{lst_t4t:itaskTemp:repeat}+]
+ temperature dht >>~ \temp -> [+\label{lst_t4t:itaskTemp:readDHT}+]
+ viewInformation [] temp <<@ [+\label{lst_t4t:itaskTemp:viewInformation}+]
+ Label "Temperature" [+\label{lst_t4t:itaskTemp:label}+]
+ )
+\end{lstClean}
+
+\begin{figure}[ht]
+ \centering
+ \begin{subfigure}[t]{.2\textwidth}
+ \centering
+ \fbox{\includegraphics[width=.9\textwidth]{readTempTask}}
+ \caption{Web page.}
+ \end{subfigure}%
+ \begin{subfigure}[t]{.8\textwidth}
+ \centering
+ \includegraphics[width=\textwidth]{simpleTempSensor}
+ \caption{Deployment diagram.}
+ \end{subfigure}
+ \caption{\Gls{ITASK} SimpleTempSensor.}%
+ \label{fig_t4t:itaskTempSimple}
+\end{figure}
+
+SimpleTempSensor only reports instantaneous temperature measurements. Extending it to store and manipulate timed temperature records produces a tiny tierless web application: TempHistory in \cref{lst_t4t:TempHistory}. A tierless \gls{IOT} system can be controlled from a web interface in exactly the same way, e.g.\ to view and set the measurement frequencies of each of the room sensors. \Cref{lst_t4t:itaskTemp:Measurement} defines a record to store \cleaninline{time} and \cleaninline{temp} measurements. Task manipulations are derived for \cleaninline{Measurement} (\cref{lst_t4t:itaskTemp:derive}) and these include displaying measurements in a web-editor and storing them in a file.
+\Cref{lst_t4t:itaskTemp:measurementsSDS} defines a persistent \gls{SDS} to store a list of measurements, and for communication between tasks. The \gls{SDS} is analogous to the SQL DBMS in many tiered web applications.
+
+TempHistory defines two tasks that interact with the \texttt{mea\-sure\-ments\-SDS}: \texttt{mea\-sure\-Task} adds measurements at each detected change in the temperature.
+It starts by defining a \cleaninline{dht} object as before, and then defines a recursive \cleaninline{task} function parameterized by the \cleaninline{old} temperature.
+This function reads the temperature from the DHT sensor and uses the step combinator, \cleaninline{>>*}, to compose it with a list of actions.
+The first of those actions that is applicable determines the continuation of this task. If no action is applicable, the task on the left-hand side is evaluated again.
+The first action checks whether the new temperature is different from the \cleaninline{old} temperature (\cref{lst_t4t:itaskTemp:action1}). If so, it records the current time and adds the new measurements to the \cleaninline{measurementsSDS}.
+The next action in \cref{lst_t4t:itaskTemp:action2} is always applicable and waits (sleeps) for an interval before returning the old temperature.
+On \cref{lst_t4t:itaskTemp:launch} \cleaninline{task} is launched with an initial temperature.
+
+\begin{lstClean}[%
+ numbers=left,
+ caption={TempHistory: a tierless \gls{CLEAN}\slash\gls{ITASK} webapplication that records and manipulates timed temperatures},
+ label={lst_t4t:TempHistory}]
+module TempHistory
+
+import iTasks, iTasks.Extensions.DateTime
+
+:: Measurement = {time :: Time, temp :: Real} [+\label{lst_t4t:itaskTemp:Measurement}+]
+derive class iTask Measurement [+\label{lst_t4t:itaskTemp:derive}+]
+
+measurementsSDS :: SimpleSDSLens [Measurement] [+\label{lst_t4t:itaskTemp:measurementsSDS}+]
+measurementsSDS = sharedStore "measurements" []
+
+measureTask :: Task () [+\label{lst_t4t:itaskTemp:measureTask}+]
+measureTask =
+ withDHT IIO_TempID \dht ->
+ let task old =
+ temperature dht >>* [+\label{lst_t4t:itaskTemp:step}+]
+ [ OnValue (ifValue ((<>) old) \temp -> [+\label{lst_t4t:itaskTemp:action1}+]
+ get currentTime >>~ \time ->
+ upd (\list.[{time=time, temp=temp}:list]) measurementsSDS
+ @! temp)
+ , OnValue (always (waitForTimer False interval @! old))[+\label{lst_t4t:itaskTemp:action2}+]
+ ] >>~ task
+ in task initialTemp [+\label{lst_t4t:itaskTemp:launch}+]
+
+
+controlSDS :: Bool -> Task [Measurement]
+controlSDS byTemp =
+ ((Label "# to take" @>> enterInformation []) -|| [+\label{lst_t4t:itaskTemp:enter}+]
+ (Label "Measurements" @>> [+\label{lst_t4t:itaskTemp:view}+]
+ viewSharedInformation
+ [ ViewAs (if byTemp (sortBy (\x y->x.temp < y.temp)) id)]
+ measurementsSDS)) >>*[+\label{lst_t4t:itaskTemp:viewend}+]
+ [ OnAction (Action "Clear") (always
+ (set [] measurementsSDS >-| controlSDS byTemp))
+ , OnAction (Action "Take") (ifValue ((<) 0)
+ (\n.upd (take n) measurementsSDS >-| controlSDS byTemp))
+ , OnAction (Action (if byTemp "Sort time" "Sort temp")) (always
+ (controlSDS (not byTemp)))
+ ] [+\label{lst_t4t:itaskTemp:actionend}+]
+
+mainTask :: Task [Measurement]
+mainTask = controlSDS False -|| measureTask
+\end{lstClean}
+
+The \cleaninline{controlSDS} task illustrates communication from the web page user and persistent data manipulation. That is, it generates a web page that allows users to control their view of the temperature measurements, as illustrated in \cref{fig_t4t:TempHistory}. The page contains
+\begin{enumerate*}
+ \item a web editor to enter the number \cleaninline{n} of elements to display, generated on \cref{lst_t4t:itaskTemp:enter}.
+ \item A display of the \cleaninline{n} most recent temperature and time measurements, \crefrange{lst_t4t:itaskTemp:view}{lst_t4t:itaskTemp:viewend}.
+ \item Three buttons that are again combined with the step combinator \cleaninline{>>*}, \crefrange{lst_t4t:itaskTemp:viewend}{lst_t4t:itaskTemp:actionend}. The \cleaninline{Clear} button is \cleaninline{always} enabled and sets the \gls{SDS} to an empty list before calling \cleaninline{controlSDS} recursively. The \cleaninline{Take} button is only enabled when the web editor produces a positive \cleaninline{n} and updates the \cleaninline{measurementsSDS} with the \cleaninline{n} most recent measurements before calling \cleaninline{controlSDS} recursively. The final action is \cleaninline{always} enabled and calls \cleaninline{controlSDS} recursively with the negation of the \cleaninline{byTemp} argument to change the sorting criteria.
+\end{enumerate*}
+
+\begin{figure}[ht]
+ \centering
+ \begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \fbox{\includegraphics[width=.95\textwidth]{TempHistory1}}
+ \caption{Web page sorted by time.}
+ \end{subfigure}%
+ \begin{subfigure}[t]{.5\textwidth}
+ \centering
+ \fbox{\includegraphics[width=.95\textwidth]{TempHistory2}}
+ \caption{Web page sorted by temperature.}
+ \end{subfigure}
+ \caption{Web pages generated by the \cleaninline{TempHistory} \gls{CLEAN}\slash\gls{ITASK} tierless web application.
+ The \cleaninline{Take} button is only enabled when the topmost editor contains a positive number.
+ }%
+ \label{fig_t4t:TempHistory}
+\end{figure}
+
+\begin{figure}[ht]
+ \centering
+ \includegraphics[width=.95\textwidth]{TempHistory}
+ \caption{Deployment diagram of the \gls{ITASK} TempHistory tierless web application from \cref{lst_t4t:TempHistory}.}%
+ \label{fig_t4t:TempHistoryDiagram}%
+\end{figure}
+
+\Cref{fig_t4t:TempHistory} shows two screenshots of web pages generated by the \cleaninline{TempHistory} program. \Cref{fig_t4t:TempHistoryDiagram} is the deployment diagram showing the addition of the persistent \cleaninline{measurementsSDS} that stores the history of temperature measurements.
+
+\subsection{Engineering tierless \texorpdfstring{\gls{IOT}}{IoT} systems with \texorpdfstring{\gls{ITASK}}{iTask}}%
+\label{sec_t4t:itaskIOT}
+
+A typical \gls{IOT} system goes beyond a web application by incorporating a distributed set of sensor nodes each with a collection of sensors or actuators. That is, they add the perception and network layers in \cref{fig_t4t:iot_arch}. If the sensor nodes have the computational resources to support an \gls{ITASK} server, as a Raspberry Pi does, then \gls{ITASK} can also be used to implement these layers, and integrate them with the application and presentation layers tierlessly.
+
+As an example of tierless \gls{IOT} programming in \gls{CLEAN}\slash\gls{ITASK} \cref{lst_t4t:itaskTempFull} shows a complete temperature sensing system with a server and a single sensor node (\gls{CRTS}), omitting only the module name and imports.
+It is similar to the SimpleTempSensor and TempHistory programs above, for example \cleaninline{devTask} repeatedly sleeps and records temperatures and times, and \cleaninline{mainTask} displays the temperatures on the web page in \cref{fig_t4t:cwtsweb}. There are some important differences, however. The \cleaninline{devTask} (\crefrange{lst_t4t:itaskTempFull:sensorfro}{lst_t4t:itaskTempFull:sensorto}) executes on the sensor node and records the temperatures in a standard timestamped (lens on) an \gls{SDS}: \cleaninline{dateTimeStampedShare} \cleaninline{latestTemp}.
+The \cleaninline{mainTask} (\cref{lst_t4t:itaskTempFull:main}) executes on the server: it starts \cleaninline{devTask} as an asynchronous task on the specified sensor node (\cref{lst_t4t:itaskTempFull:startdevtask}) and then generates a web page to display the latest temperature and time (\cref{lst_t4t:itaskTempFull:displaystart,lst_t4t:itaskTempFull:displayend}).
+
+The \cleaninline{tempSDS} is very similar to the \cleaninline{measurementsSDS} from the previous listings.
+The only difference is that we store measurements as tuples instead of tailor-made records.
+The \cleaninline{latestTemp} is a \emph{lens} on the \cleaninline{tempSDS}.
+A lens is a new \gls{SDS} that is automatically mapped to another \gls{SDS}.
+Updating one of the \glspl{SDS} that are coupled in this way automatically updates the other.
+The function \cleaninline{mapReadWrite} is parameterized by the read and write functions, the option to handle asynchronous update conflicts (here \cleaninline{?None}) and the \gls{SDS} to be transformed (here \cleaninline{tempSDS}).
+The result of reading is the head of the list, if it exists.
+The type for writing \cleaninline{latestTemp} is a tuple with a new \cleaninline{DateTime} and temperature as \cleaninline{Real}.
+
+\begin{lstClean}[%
+ numbers=left,
+ caption={\gls{CRTS}: a tierless temperature sensing \gls{IOT} system. Written in \gls{CLEAN}\slash\gls{ITASK}, it targets a resource-rich sensor node.},
+ label={lst_t4t:itaskTempFull}]
+tempSDS :: SimpleSDSLens [(DateTime, Real)]
+tempSDS = sharedStore "temperatures" []
+
+latestTemp :: SDSLens () (? (DateTime, Real)) (DateTime, Real)
+latestTemp = mapReadWrite (listToMaybe, \x xs-> ?Just [x:xs]) ?None tempSDS
+
+devTask :: Task DateTime
+devTask = [+\label{lst_t4t:itaskTempFull:sensorfro}+]
+ withDHT IIO_TempID \dht ->
+ forever ([+\label{lst_t4t:itaskTempFull:forever}+]
+ temperature dht >>~ \temp ->
+ set temp (dateTimeStampedShare latestTemp) >-|
+ waitForTimer False interval) [+\label{lst_t4t:itaskTempFull:waitForTimer}+][+\label{lst_t4t:itaskTempFull:sensorto}+]
+
+mainTask :: Task ()
+mainTask [+\label{lst_t4t:itaskTempFull:main}+]
+ = asyncTask deviceInfo.domain deviceInfo.port devTask [+\label{lst_t4t:itaskTempFull:startdevtask}+]
+ -|| viewSharedInformation [] [+\label{lst_t4t:itaskTempFull:displaystart}+]
+ (remoteShare latestTemp deviceInfo) [+\label{lst_t4t:itaskTempFull:remoteShare}+]
+ <<@ Title "Latest temperature" [+\label{lst_t4t:itaskTempFull:displayend}+]
+\end{lstClean}
+
+\begin{figure}[ht]
+ \centering
+ \begin{subfigure}[t]{.2\textwidth}
+ \centering
+ \fbox{\includegraphics[width=.9\textwidth]{cwts}}
+ \caption{Web page.}
+ \end{subfigure}%
+ \begin{subfigure}[t]{.8\textwidth}
+ \centering
+ \includegraphics[width=\textwidth]{devTaskDiagram2}
+ \caption{Deployment diagram.}
+ \end{subfigure}
+ \caption{Tierless \gls{ITASK} \gls{CRTS} temperature sensing \gls{IOT} system.}%
+ \label{fig_t4t:cwtsweb}
+\end{figure}
+
+\subsection{The \texorpdfstring{\gls{MTASK}}{mTask} \texorpdfstring{\gls{EDSL}}{eDSL}}%
+\label{sec_t4t:mtasks}
+
+In many \gls{IOT} systems the sensor nodes are resource constrained, e.g.\ inexpensive microcontrollers. These are far cheaper, and consume far less power, than a single-board computer like a Raspberry Pi. Microcontrollers also allow the programmer to easily control peripherals like sensors and actuators via the \gls{IO} pins of the processor.
+
+Microcontrollers have limited memory capacity, compute power and communication bandwidth, and hence typically no \gls{OS}.
+These limitations make it impossible to run an \gls{ITASK} server:
+there is no \gls{OS} to start the remote task, the code of the task is too big to fit in the available memory and the microcontroller processor is too slow to run it.
+The \gls{MTASK} \gls{EDSL} is designed to bridge this gap: \gls{MTASK} tasks can be communicated from the server to the sensor node, to execute within the limitations of a typical microcontroller, while providing programming abstractions that are consistent with \gls{ITASK}.
+
+Like \gls{ITASK}, \gls{MTASK} is task oriented, e.g.\ there are primitive tasks that produce intermediate values, a restricted set of task combinators to compose the tasks, and (recursive) functions to construct tasks.
+\Gls{MTASK} tasks communicate using task values or \glspl{SDS} that may be local or remote, and may be shared by some \gls{ITASK} tasks.
+
+Apart from the \gls{EDSL}, the \gls{MTASK} system contains a featherlight domain-specific \emph{operating system} running on the microcontroller.
+This \gls{OS} task scheduler receives the byte code generated from one or more \gls{MTASK} programs and interleaves the execution of those tasks. The \gls{OS} also manages \gls{SDS} updates and the passing of task results.
+The \gls{MTASK} \gls{OS} is stored in flash memory while the tasks are stored in \gls{RAM} to minimise wear on the flash memory. While sending byte code to a sensor node at runtime greatly increases the amount of communication, this can be mitigated as any tasks known at compile time can be preloaded on the microcontroller.
+In contrast, compiled programs, like \gls{C}\slash\gls{CPP}, are stored in flash memory and there can only ever be a few thousand programs uploaded during the lifetime of the microcontroller before exhausting the flash memory.
+
+\subsection{Engineering tierless \texorpdfstring{\gls{IOT}}{IoT} systems with \texorpdfstring{\gls{MTASK}}{mTask}}%
+\label{sec_t4t:mtaskIOT}
+
+A tierless \gls{CLEAN} \gls{IOT} system with microcontroller 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 microcontroller.
+
+\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.
+The body of \cleaninline{devTask} is the \gls{MTASK} slice of the program (\crefrange{lst_t4t:mtaskTemp:DHT}{lst_t4t:mtaskTemp:setSds}).
+With \cleaninline{DHT} we again create a temperature sensor object \cleaninline{dht}.
+The \gls{ITASK} \gls{SDS} \cleaninline{latestTemp} is first transformed to a \gls{SDS} that accepts only temperature values,
+the \cleaninline{dateTimeStampedShare} adds the data via a lens.
+The \cleaninline{mapRead} adjusts the read type.
+This new \gls{SDS} of type \cleaninline{Real} is lifted to the \gls{MTASK} program with \cleaninline{liftsds}.
+%The \cleaninline{mapRead} ensures that every write to \cleaninline{localSds} is automatically time-stamped when it is written to \cleaninline{latestTemp}.
+
+
+The \cleaninline{mainTask} is a simple \gls{ITASK} task that starts the \cleaninline{devTask} \gls{MTASK} task on the device identified by \cleaninline{deviceInfo} (\cref{lst_t4t:mtaskTemp:withdevice}). At runtime the \gls{MTASK} slice is compiled to byte code, shipped to the indicated device, and launched. Thereafter, \cleaninline{mainTask} reads temperature values from the \cleaninline{latestTemp} \gls{SDS} that is shared with the \gls{MTASK} device, and displays them on a web page (\cref{fig_t4t:cwtsweb}). The \gls{SDS}---shared with the device using \cleaninline{liftsds}---automatically communicates new temperature values from the microcontroller to the server.
+
+While this simple application makes limited use of the \gls{MTASK} \gls{EDSL}, it illustrates some powerful \gls{MTASK} program abstractions like basic tasks, task combinators, named recursive and parameterized tasks, and \glspl{SDS}.
+Function composition (\cref{lst_t4t:mtaskTemp:o}) and currying (\cref{lst_t4t:mtaskTemp:setSds}) are inherited from the \gls{CLEAN} host language.
+As \gls{MTASK} tasks are dynamically compiled, it is also possible to select and customise tasks as required at runtime.
+For example, the interval used in the \cleaninline{rpeatevery} task (\cref{lst_t4t:mtaskTemp:rpeatevery}) could be a parameter to the \cleaninline{devTask} function.
+
+\newcommand{\srcmark}[1]{\marginpar[\small\emph{#1}]{\small\emph{#1}}}
+\begin{lstClean}[%
+ numbers=left,
+ caption={
+ \Gls{CWTS}: a tierless temperature sensing \gls{IOT} system. Written in \gls{CLEAN}\slash\gls{ITASK}/\gls{MTASK}, it targets a resource-constrained sensor node. Each line is annotated with the functionality as analysed in \cref{sec_t4t:codesize}.},
+ label={lst_t4t:mtaskTemp},
+]
+module cwts
+
+import mTask.Language, mTask.Interpret, mTask.Interpret.Device.TCP
+import iTasks, iTasks.Extensions.DateTime
+
+deviceInfo = {TCPSettings|host="...", port=8123, pingTimeout= ?None} [+\label{lst_t4t:mtaskTemp:co0}\srcmark{CO}+]
+interval = lit 10[+\label{lst_t4t:mtaskTemp:sn0}\srcmark{SN}+]
+DHT_pin = DigitalPin D4[+\label{lst_t4t:mtaskTemp:si0}\srcmark{SI}+]
+
+Start world = doTasks mainTask world[+\label{lst_t4t:mtaskTemp:wi0}\srcmark{WI}+]
+
+tempSDS :: SimpleSDSLens [(DateTime, Real)]
+tempSDS = sharedStore "temperatures" [][+\label{lst_t4t:mtaskTemp:di0}\srcmark{DI}+]
+
+latestTemp :: SDSLens () (? (DateTime, Real)) (DateTime, Real)
+latestTemp = mapReadWrite (listToMaybe, \x xs-> ?Just [x:xs]) ?None tempSDS[+\label{lst_t4t:mtaskTemp:di1}\srcmark{DI}+]
+
+devTask :: Main (MTask v Real) | mtask, dht, liftsds v[+\label{lst_t4t:mtaskTemp:devTask}+]
+devTask =
+ DHT (DHT_DHT DHT_pin DHT11) \dht ->[+\label{lst_t4t:mtaskTemp:DHT}+][+\label{lst_t4t:mtaskTemp:si1}\srcmark{SI}+]
+ liftsds \localSds =[+\label{lst_t4t:mtaskTemp:liftsds}+][+\label{lst_t4t:mtaskTemp:co1}\srcmark{CO}+]
+ mapRead (snd o fromJust) (dateTimeStampedShare latestTemp)[+\label{lst_t4t:mtaskTemp:o}+][+\label{lst_t4t:mtaskTemp:sn1}\srcmark{SN}+]
+ In {main = rpeatEvery (ExactSec interval)[+\label{lst_t4t:mtaskTemp:rpeatevery}+][+\label{lst_t4t:mtaskTemp:sn2}\srcmark{SN}+]
+ (temperature dht >>~.[+\label{lst_t4t:mtaskTemp:temperature}+][+\label{lst_t4t:mtaskTemp:si2}\srcmark{SI}+]
+ setSds localSds)}[+\label{lst_t4t:mtaskTemp:setSds}+][+\label{lst_t4t:mtaskTemp:sn3}\srcmark{SN}+]
+
+mainTask :: Task Real
+mainTask
+ = withDevice deviceInfo \dev -> liftmTask} devTask dev[+\label{lst_t4t:mtaskTemp:liftmtask}+][+\label{lst_t4t:mtaskTemp:withdevice}+][+\label{lst_t4t:mtaskTemp:co2}\srcmark{CO}+]
+ -|| viewSharedInformation [] latestTemp[+\label{lst_t4t:mtaskTemp:wi1}\srcmark{WI}+]
+ <<@ Title "Latest temperature"[+\label{lst_t4t:mtaskTemp:wi2}+] // WI
+\end{lstClean}
+%
+
+\begin{figure}[ht]
+ \centering
+ \begin{subfigure}[t]{.2\textwidth}
+ \centering
+ \fbox{\includegraphics[width=.9\textwidth]{cwts}}
+ \caption{Web page.}
+ \end{subfigure}%
+ \begin{subfigure}[t]{.8\textwidth}
+ \centering
+ \includegraphics[width=.95\textwidth]{cwtsDiagram2}
+ \caption{Deployment diagram.}
+ \end{subfigure}
+ \caption{Tierless \gls{ITASK}\slash\gls{MTASK} \gls{CWTS} temperature sensing \gls{IOT} system.}%
+ \label{fig_t4t:cwtsDiagram}
+\end{figure}
+
+\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 microcontroller 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.
+
+%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 microcontroller.
+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.
+
+\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.
+
+\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}}.%
+ \end{subfigure}%
+ \begin{subfigure}[t]{.49\textwidth}
+ \centering
+ \includegraphics[width=.9\textwidth]{prss}
+ \caption{A Raspberry Pi used in \gls{PRS} and \gls{CRS}.}%
+ \end{subfigure}
+ \caption{Exposed views of sensor nodes.}%%
+ \label{fig_t4t:wemos_prss}
+\end{figure}
+
+\subsection{Tiered implementations}
+The tiered \gls{PRS} and \gls{PWS} share the same server code executing on a commodity PC (\cref{fig_t4t:iot_arch}). The \gls{PYTHON} server stores incoming sensor data in two database systems, i.e.\ Redis (in-memory data) and MongoDB (persistent data). The real-time sensor data is made available via a streaming websockets server, which connects with Redis.
+There is also an HTTP REST \gls{API} for polling current and historical sensor data, which hooks into {MongoDB}.
+Communication between a sensor node and the server is always initiated by the node.
+
+\Gls{PRS}'s sensor nodes are %powered by the
+relatively powerful Raspberry Pi 3 Model Bs. There is a simple object-oriented \gls{PYTHON} collector for configuring the sensors and reading their values. The collector daemon service marshals the sensor data and transmits using \gls{MQTT} to the central monitoring server at a preset frequency.
+The collector caches sensor data locally when the server is unreachable.
+
+In contrast to \gls{PRS}, \gls{PWS}'s sensor nodes are microcontrollers running \gls{MICROPYTHON}, a dialect of \gls{PYTHON} specifically designed to run on small, low powered embedded devices~\cite{kodali2016low}.
+To enable a fair comparison between the software stacks we are careful to use the same object-oriented software architecture, e.g.\ using the same classes in \gls{PWS} and \gls{PRS}.
+
+\Gls{PYTHON} and \gls{MICROPYTHON} are appropriate tiered comparison languages. Tiered \gls{IOT} systems are implemented in a whole range of programming languages, with \gls{PYTHON}, \gls{MICROPYTHON}, \gls{C} and \gls{CPP} being popular for some tiers in many implementations. \gls{C}\slash\gls{CPP} implementations would probably result in more verbose programs and even less type safety.
+The other reasons for selecting \gls{PYTHON} and \gls{MICROPYTHON} are pragmatic. \gls{PRS} had been constructed in \gls{PYTHON}, deployed, and was being used as an \gls{IOT} experimental platform.
+Selecting \gls{MICROPYTHON} for the resource-constrained \gls{PWS} sensor nodes facilitates comparison by minimising changes to the resource-rich and resource-constrained codebases.
+We anticipate that the codebase for a tiered smart campus implementation in another imperative/object-oriented language, like \gls{CPP}, would be broadly similar to the \gls{PRS} and \gls{PWS} codebases.
+
+\subsection{Tierless implementations}
+
+The tierless \gls{CRS} and \gls{CWS} servers share the same \gls{ITASK} server code (\cref{fig_t4t:iot_arch}), and can be compiled for many standard platforms.
+They use
+SQLite as a database backend.
+Communication between a sensor node and the server is initiated by the server.
+
+\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~\cite{oortgiese_distributed_2017}.
+
+\Gls{CWS}'s sensor nodes are Wemos microcontrollers 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
+ \begin{subfigure}[t]{.49\textwidth}
+ \centering
+ \fbox{\includegraphics[width=.75\textwidth]{cwss_web}}
+ \caption{\Gls{CWS} and \gls{CRS}.}
+ \end{subfigure}%
+ \begin{subfigure}[t]{.49\textwidth}
+ \centering
+ \fbox{\includegraphics[width=.75\textwidth, height=.2\textheight, keepaspectratio]{sensordata.png}}
+ \caption{\Gls{PWS} and \gls{PRS}.}
+ \end{subfigure}
+ \caption{Web interfaces for the smart campus application.}%
+ \label{fig_t4t:webinterfaces}
+\end{figure}
+
+\subsection{Operational Equivalence}%
+\label{sec_t4t:OperationalComparison}
+
+
+To ensure that the comparison reported in the following sections is based on \gls{IOT} stacks with equivalent functionality, we demonstrate that \gls{PWS}, \gls{CWS} and \gls{CRS}, like \gls{PRS}, meet the functional requirements for the \gls{UOG} smart campus sensor system. We also compare the sensor node power consumption and memory footprint.
+
+\subsubsection{Functional Requirements}%
+\label{sec_t4t:Validation}
+
+The main goal of the \gls{UOG} smart campus project is to provide a testbed for sensor nodes and potentially other devices to act as a data collection and computation platform for the \gls{UOG} smart campus. The high-level functional requirements, as specified by the \gls{UOG} smart campus project board, are as follows. The system should:
+%\mlcomment{can be inline as well}
+\begin{enumerate}
+
+ \item be able to measure temperature and humidity as well as light intensity,
+
+ \item scale to no more than 10 sensors per sensor node and investigate further sensor options like measuring sound levels,
+
+ \item have access to communication channels like WiFi, Bluetooth and even wired networks.
+
+ \item have a centralised database server,
+
+ \item have a client interface to access information stored in the database,
+
+ \item provide some means of security and authentication,
+ %\item have some means of providing security and authentication.
+
+ \item have some means of managing and monitoring sensor nodes like updating software or detecting new sensor nodes.
+
+\end{enumerate}
+All four smart campus implementations meet these high-level requirements.
+
+\subsubsection{Functional Equivalence}
+
+Observation of the four implementations shows that they operate as expected, e.g.\ detecting light or motion. To illustrate \cref{fig_t4t:webinterfaces} shows the web interface for the implementations where \gls{CWS} and \gls{CRS} are deployed in a different room from \gls{PWS} and \gls{PRS}.
+
+All four implementations use an identical set of inexpensive sensors, so we expect the accuracy of the data collected is within tolerance levels. This is validated by comparing \gls{PRS} and \gls{PWS} sensor nodes deployed in the same room for some minutes. The measurements show only small variances, e.g.\ temperatures recorded differ by less than \qty{0.4}{\celcius}, and light by less than \qty{1}{lux}. For this room monitoring application precise timings are not critical, and we don't compare the timing behaviours of the implementations.
+%\adriancomment{Maybe include a reference for accepted standards of variation between the same type of sensors?}
+% Phil: lets see what the reviewers say
+
+
+\subsubsection{Memory and Power Consumption}%
+%\subsubsection{Memory Consumption}%
+\label{sec_t4t:MemPower}
+
+\paragraph{Memory} By design sensor nodes are devices with limited computational capacity, and memory is a key restriction. Even supersensors often have less than a \unit{\gibi\byte} of memory, and microcontrollers often have just tens of \unit{\kibi\byte{}s}.
+%In a tiered implementation the memory residency of the sensor node code can be minimised by carefully crafting it in a language that minimises memory residency. However, ...
+As the tierless languages synthesize the code to be executed on the sensor nodes, we need to confirm that the generated code is sufficiently memory efficient.
+
+\begin{table}
+ \centering
+ \caption{\Gls{UOG} smart campus sensor nodes: maximum memory residency (in bytes).}%
+ \label{tbl_t4t:mem}
+ \begin{tabular}{rrrr}
+ \toprule
+ \multicolumn{1}{c}{\gls{PWS}} & \multicolumn{1}{c}{\gls{PRS}} & \multicolumn{1}{c}{\gls{CWS}} & \multicolumn{1}{c}{\gls{CRS}}\\
+ \midrule
+ \num{20270} & \num{3557806} & \num{880} & \num{2726680}\\
+ \bottomrule
+ \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 microcontrollers 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~\cite{plamauer2017evaluation}.
+
+The smart campus sensor node programs executing on the Raspberry Pis have far higher maximum residencies than those executing on the microcontrollers: \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.
+%The memory used is actually very similar to the memory usage of the server with a single client connected.
+In \gls{PRS} the sensor node program is written in \gls{PYTHON}, a language far less focused on minimising memory usage than \gls{MICROPYTHON}. For example an object like a string is larger in \gls{PYTHON} than in \gls{MICROPYTHON} and consequently does not support all features such as \emph{f-strings}.
+Furthermore, not all advanced \gls{PYTHON} feature regarding classes are available in \gls{MICROPYTHON}, i.e.\ only a subset of the \gls{PYTHON} specification is supported~\cite{diffmicro}.%\mlcomment{reference \url{https://docs.micropython.org/en/latest/genrst/index.html} ? It contains an overview of supported features}
+
+In summary the sensor node code generated by both tierless languages, \gls{ITASK} and \gls{MTASK}, is sufficiently memory efficient for the target sensor node hardware. Indeed, the maximum residencies of the \gls{CLEAN} sensor node code is less than the corresponding hand-written (Micro)\gls{PYTHON} code. Of course in a tiered stack the hand-written code can be more easily optimised to minimise residency, and this could even entail using a memory efficienthat thet language like \gls{C}\slash\gls{CPP}. However, such optimisation requires additional developer effort, and a new language would introduce additional semantic friction.
+
+\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}}
+%\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 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 microcontroller sensor node consumes an order of magnitude less power than a supersensor node.
+
+
+\section{Is Tierless \texorpdfstring{\gls{IOT}}{IoT} Programming Easier than Tiered?}%
+\label{sec_t4t:ProgrammingComparison}
+
+
+This section investigates whether tierless languages make \gls{IOT} programming \emph{easier} by comparing the \gls{UOG} smart campus implementations. The \gls{CRS} and \gls{CWS} implementations allow us to evaluate tierless languages for
+ resource-rich and for resource-constrained sensor nodes respectively. The \gls{PRS} and \gls{PWS} allow a like-for-like comparison with tiered \gls{PYTHON} implementations.
+
+
+%\subsection{Temperature Sensor Illustration}
+
+\subsection{Comparing Tiered and Tierless Codebases}%
+\label{sec_t4t:codesize}
+%A comparison of the Temperature sensor in \gls{PYTHON} Micropyton, Itask \& \gls{MTASK}.
+
+\paragraph{Code Size} is widely recognised as an approximate measure of the development and maintenance effort required for a software system~\cite{rosenberg1997some}. \gls{SLOC} is a common code size metric, and is especially useful for multi-paradigm systems like \gls{IOT} systems. It is based on the simple principle that the more \gls{SLOC}, the more developer effort and the increased likelihood of bugs~\cite{rosenberg1997some}. It is a simple measure, not dependent on some formula, and can be automatically computed~\cite{sheetz2009understanding}.
+
+Of course \gls{SLOC} must be used carefully as it is easily influenced by programming style, language paradigm, and counting method~\cite{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).
+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.
+Manage Nodes (MN) is code that coordinates sensor nodes, e.g.\ to add a new sensor node to the system. % formerly device management
+Web Interface (WI) code provides the web interface from the server, i.e.\ the presentation layer.
+Database Interface (DI) code communicates between the server and the database\strut(s).
+Communication (CO) code provides communication between the server and the sensor nodes, and executes on both sensor node and server, i.e.\ the network layer.
+
+The most striking information in \cref{table_t4t:multi} is that \emph{the tierless implementations require far less code than the tiered implementations}. For example 166/562 \gls{SLOC} for \gls{CWS}\slash\gls{PWS}, or 70\% fewer \gls{SLOC}. We attribute the code reduction to three factors: reduced interoperation, automatic communication, and high level programming abstractions. We analyse each of these aspects in the following subsections.
+
+\begin{table}
+ \centering % used for centering table
+ \caption{Comparing tiered and tierless smart campus code sizes: \gls{SLOC} and number of source files. \gls{PWS} and \gls{CWS} execute on resource-constrained sensor nodes, while \gls{PRS} and \gls{CRS} execute on resource-rich sensor nodes.}%
+ \label{table_t4t:multi}
+ \begin{tabular}{l l c c c c } % centered columns (4 columns)
+ \toprule
+ & & \multicolumn{2}{c}{Tiered \gls{PYTHON}} & \multicolumn{2}{c}{Tierless \gls{CLEAN}} \\
+ Code location & Functionality & \gls{PWS} & \gls{PRS} & \gls{CWS} & \gls{CRS} \\
+ \midrule
+ Sensor Node & Sensor Interface & 52 & 57 & 11 & 11\\
+ & Sensor Node & 178 & 183 & 9 & 4\\
+ \midrule
+ Server & Manage Nodes & \multicolumn{2}{c}{76} & 35 & 30\\
+ & Web Interface & \multicolumn{2}{c}{56} & \multicolumn{2}{c}{28}\\
+ & Database Interface & \multicolumn{2}{c}{106} & \multicolumn{2}{c}{78}\\
+ \midrule
+ Communication & Communication & 94 & 98 & 5 & 4\\
+ \midrule
+ Total \gls{SLOC} & & 562 & 576 & 166 & 155 \\
+ \textnumero{} Files & & 35 & 38 & 3 & 3 \\
+ \bottomrule
+ \end{tabular}
+\end{table}
+
+\paragraph{Code Proportions.} Comparing the percentages of code required to implement the smart campus functionalities normalises the data and avoids some issues when comparing \gls{SLOC} for different programming languages, and especially for languages with different paradigms like object-oriented \gls{PYTHON} and functional \gls{CLEAN}. \Cref{fig_t4t:multipercentage} shows the percentage of the total \gls{SLOC} required to implement the smart campus functionalities in each of the four implementations, and is computed from the data in \cref{table_t4t:multi}. It shows that there are significant differences between the percentage of code for each functionality between the tiered and tierless implementations. For example 17\% of the tiered implementations specifies communication, whereas this requires only 3\% of the tierless implementations, i.e.\ 6$\times$ less. We explore the reasons for this in \cref{sec_t4t:Communication}. The other major difference is the massive percentage of Database Interface code in the tierless implementations: at least 47\%. The smart campus specification required a standard DBMS, and the \gls{CLEAN}\slash\gls{ITASK} SQL interface occupies some 78 \gls{SLOC}. While this is a little less than the 106 \gls{SLOC} used in \gls{PYTHON} (\cref{table_t4t:multi}), it is a far higher percentage of systems with total codebases of only around 160 \gls{SLOC}. Idiomatic \gls{CLEAN}/\gls{ITASK} would use high level abstractions to store persistent data in an \gls{SDS}, requiring just a few \gls{SLOC}.
+The total size of \gls{CWS} and \gls{CRS} would be reduced by a factor of two and the percentage of Database Interface code would be even less than in the tiered \gls{PYTHON} implementations.
+
+
+\begin{figure}
+ \centering
+ \includegraphics[width=.7\linewidth]{bar_chart.pdf}
+ \caption{Comparing the percentage of code required to implement each functionality in tiered/tierless and resource-rich/constrained smart campus implementations.}%
+ \label{fig_t4t:multipercentage}
+\end{figure}
+
+\subsection{Comparing Codebases for Resource-Rich/Constrained Sensor Nodes}%
+\label{sec_t4t:resourcerich}
+
+Before exploring the reasons for the smaller tierless codebase we compare the implementations for resource-rich and resource-constrained sensor nodes, again using \gls{SLOC} and code proportions. \Cref{table_t4t:multi} shows that the two tiered implementations are very similar in size: with \gls{PWS} for microcontrollers requiring 562 \gls{SLOC} and \gls{PRS} for supersensors requiring 576 \gls{SLOC}.
+The two tierless implementations are also similar in size: \gls{CWS} requiring 166 and \gls{CRS} 155 \gls{SLOC}.
+
+There are several main reasons for the similarity. One is that the server-side code, i.e.\ for the presentation and application layers, is identical for both resource rich/constrained implementations. The identical server code accounts for approximately 40\% of the \gls{PWS} and \gls{PRS} codebases, and approximately 85\% of the \gls{CWS} and \gls{CRS} codebases (\cref{fig_t4t:multipercentage}). For the perception and network layers on the sensor nodes, the \gls{PYTHON} and \gls{MICROPYTHON} implementations have the same structure, e.g.\ a class for each type of sensor, and use analogous libraries. Indeed, approaches like CircuitPython~\cite{CircuitPython} allow the same code to execute on both resource-rich and resource-constrained sensor nodes.
+
+
+Like \gls{PYTHON} and \gls{MICROPYTHON}, \gls{ITASK} and \gls{MTASK} are designed to be similar, as elaborated in \cref{sec_t4t:ComparingTierless}. The similarity is apparent when comparing the \gls{ITASK} \gls{CRTS} and \gls{ITASK}\slash\gls{MTASK} \gls{CWTS} room temperature systems in \cref{lst_t4t:itaskTempFull,lst_t4t:mtaskTemp}. That is, both implementations use similar \glspl{SDS} and lenses; they have similar \cleaninline{devTask}s that execute on the sensor node, and the server-side \cleaninline{mainTask}s are almost identical: they deploy the remote \cleaninline{devTask} before generating the web page to report the readings.
+
+In both \gls{PYTHON} and \gls{CLEAN} the resource-constrained implementations are less than 7\% larger than the resource-rich implementations. This suggests that \emph{the development and maintenance effort of simple \gls{IOT} systems for resource-constrained and for resource-rich sensor nodes is similar in tierless technologies,} just as it is in tiered technologies.
+A caveat is that the smart campus system is relatively simple, and developing more complex perception and network code on bare metal may prove more challenging. That is, the lack of \gls{OS} support, and the restricted languages and libraries, may have greater impact. We return to this issue in \cref{sec_t4t:ComparingTierless}.
+
+
+\subsection{Reduced Interoperation}%
+\label{sec_t4t:interoperation}
+\begin{table}
+ \centering
+ \small
+ \caption{Smart campus implementation languages comparison.}%
+ \label{table_t4t:languages}
+ \begin{tabular}{lllllll}
+ \toprule
+ & & \multicolumn{4}{c}{Languages}\\
+ \midrule
+ Code Location & Functionality & \gls{PWS} & \gls{PRS} & \gls{CWS} & \gls{CRS}\\
+ \midrule
+ Sensor Node & Sensor Int. & \gls{MICROPYTHON} & \gls{PYTHON} & \gls{MTASK} & \gls{ITASK}\\
+ & Sensor Node & \gls{MICROPYTHON} & \gls{PYTHON} & \gls{MTASK} & \gls{ITASK}\\
+ \midrule
+ Server & Manage Nodes & \multicolumn{2}{c}{\gls{PYTHON}, \gls{JSON}} & \multicolumn{2}{c}{\gls{ITASK}}\\
+ & Web Int. & \multicolumn{2}{c}{HTML, PHP} & \multicolumn{2}{c}{\gls{ITASK}}\\
+ & Database Int. & \multicolumn{2}{c}{\gls{PYTHON},\gls{JSON},Redis} & \multicolumn{2}{c}{\gls{ITASK}}\\
+ \midrule
+ Communication & Communication & \gls{MICROPYTHON} & \gls{PYTHON} & \gls{ITASK},\gls{MTASK} & \gls{ITASK}\\
+ \midrule
+ & Total & 7 & 6 & 2 & 1\\
+ \bottomrule
+ \end{tabular}
+\end{table}
+
+\begin{table}
+ \centering
+ \small
+ \caption{Smart campus paradigm comparison.}%
+ \label{table_t4t:paradigms}
+ \begin{tabular}{llll}
+ \toprule
+ & & \multicolumn{2}{c}{Paradigms}\\
+ \midrule
+ Code Location & Functionality & \gls{PYTHON} & \gls{CLEAN}\\
+ \midrule
+ Sensor Node & Sensor Int. & imperative & declarative\\
+ & Sensor Node & imperative & declarative\\
+ \midrule
+ Server & Manage Nodes & imperative & declarative\\
+ & Web Int. & both & declarative\\
+ & Database Int. & both & declarative\\
+ \midrule
+ Communication & Communication & imperative & declarative\\
+ \midrule
+ & Total & 2 & 1 \\
+ \bottomrule
+ \end{tabular}
+\end{table}
+
+The vast majority of \gls{IOT} systems are implemented using a number of different programming languages and paradigms, and these must be effectively used and interoperated. A major reason that the tierless \gls{IOT} implementations are simpler and shorter than the tiered implementations is that they use far fewer programming languages and paradigms. Here we use language to distinguish \glspl{EDSL} from their host language: so \gls{ITASK} and \gls{MTASK} are considered distinct from \gls{CLEAN}; and to distinguish dialects: so \gls{MICROPYTHON} is considered distinct from \gls{PYTHON}.
+
+The tierless implementations use just two conceptually-similar \glspl{DSL} embedded in the same host language, and a single paradigm (\cref{table_t4t:languages,table_t4t:paradigms}). In contrast, the tiers in \gls{PRS} and \gls{PWS} use six or more very different languages, and both imperative and declarative paradigms. Multiple languages are commonly used in other typical software systems like web stacks, e.g.\ a recent survey of open source projects reveals that on average at least five different languages are used~\cite{mayer2015empirical}. Interoperating components in multiple languages and paradigms raises a plethora of issues.
+
+Interoperation \emph{increases the cognitive load on the developer} who must simultaneously think in multiple languages and paradigms. This is commonly known as semantic friction or impedance mismatch~\cite{ireland2009classification}. A simple illustration of this is that the tiered \gls{PRS} source code comprises some 38 source and configuration files, whereas the tierless \gls{CRS} requires just 3 files (\cref{table_t4t:multi}). The source could be structured as a single file, but to separate concerns is structured into three modules, one each for \glspl{SDS}, types, and control logic~\cite{wang_maintaining_2018}.
+
+The developer must \emph{correctly interoperate the components}, e.g.\ adhere to the \gls{API} or communication protocols between components. The interoperation often entails additional programming tasks like marshalling or demarshalling data between components. For example, in the tiered \gls{PRS} and \gls{PWS} architectures, \gls{JSON} is used to serialise and deserialise data strings from the \gls{PYTHON} collector component before storing the data in the Redis database (\cref{lst_t4t:json}).
+%e.g.\ to marshall and demarshall data between components.
+
+%\mlcomment{A listing must have a caption for it to be labeled and referenced}
+\begin{lstPython}[caption={\Gls{JSON} Data marshalling in \gls{PRS} and \gls{PWS}: sensor node above, server below.},label={lst_t4t:json}]
+
+channel = 'sensor_status.%s.%s' % (hostname,
+ sensor_types.sensor_type_name(s.sensor_type))
+ self.r.publish(channel, s.SerializeToString())
+
+[+\dotfill+]
+
+for message in p.listen():
+ if message['type'] not in ['message', 'pmessage']:
+ continue
+
+try:
+ status = collector_pb2.SensorStatus.FromString(message['data'])
+\end{lstPython}
+
+To ensure correctness the developer \emph{must maintain type safety} across a range of very different languages and diverse type systems, and we explore this further in \cref{sec_t4t:typesafety}. The developer must also deal with the \emph{potentially diverse failure modes}, not only of each component, but also of their interoperation, e.g.\ if a value of an unexpected type is passed through an \gls{API}. We explore this further in \cref{sec_t4t:NetworkManagement}.
+
+\subsection{Automatic Communication}%
+\label{sec_t4t:Communication}
+
+In conventional tiered \gls{IOT} implementations the developer must write and maintain code to communicate between tiers. For example \gls{PRS} and \gls{PWS} create, send and read \gls{MQTT}~\cite{light2017mosquitto} messages
+between the perception and application layers. \Cref{table_t4t:multi} shows that communication between these layers require some 94 \gls{SLOC} in \gls{PWS} and 98 in \gls{PRS}, accounting for 17\% of the codebase (bottom bars in \cref{fig_t4t:multipercentage}). To illustrate, \cref{lst_t4t:mwssmqtt} shows part of the code to communicate sensor readings from the \gls{PWS} sensor node to the Redis store on the server.
+
+Not only must the tiered developer write additional code, but \gls{IOT} communication code is often intricate. In such a distributed system the sender and receiver must be correctly configured, correctly follow the communication protocol through all execution states, and deal with potential failures. For example line 3 of \cref{lst_t4t:mwssmqtt}: \pythoninline{redis host = config.get('Redis', 'Host')} will fail if either the host or IP are incorrect.
+
+\begin{lstPython}[caption={Tiered communication example: \gls{MQTT} transmission of sensor values in \gls{PWS}.},label={lst_t4t:mwssmqtt}]
+def main():
+ config.init('mqtt')
+ redis_host = config.get('Redis', 'Host')
+ redis_port = config.getint('Redis', 'Port')
+ r = redis.StrictRedis(host=redis_host, port=redis_port)
+ p = r.pubsub()
+ p.psubscribe("sensor_status.*")
+ for message in p.listen():
+ if message['type'] not in ['message', 'pmessage']:
+ print "Ignoring message %s" % message
+ [+\ldots+]
+\end{lstPython}
+
+In contrast, the tierless \gls{CWS} and \gls{CRS} communication is not only highly automated, but also automatically correct because matching sender and receiver code is generated by the compiler. \Cref{table_t4t:multi} shows that communication is specified in just 5 \gls{SLOC} in \gls{CWS} and 4 in \gls{CRS}, or just 3\% of the codebase (bottom bars in \cref{fig_t4t:multipercentage}).
+
+
+\Cref{lst_t4t:mtaskTemp} illustrates communication in a tierless \gls{IOT} language. That is, the \gls{CWTS} temperature sensor requires just three lines of communication code, and uses just three communication functions. The
+\cleaninline{withDevice} function on \cref{lst_t4t:mtaskTemp:withdevice} integrates a sensor node with the server, allowing tasks to be sent to it. The
+\cleaninline{liftmTask} on \cref{lst_t4t:mtaskTemp:liftmtask} integrates an \gls{MTASK} in the \gls{ITASK} runtime by compiling it and sending it for interpretation to the sensor node.
+The \cleaninline{liftsds} on \cref{lst_t4t:mtaskTemp:liftsds} integrates \glspl{SDS} from \gls{ITASK} into \gls{MTASK}, allowing \gls{MTASK} tasks to interact with data from the \gls{ITASK} server.
+The exchange of data, user interface, and communication are all automatically generated.
+
+\subsection{High Level Abstractions}%
+\label{sec_t4t:abstractions}
+
+Another reason that the tierless \gls{CLEAN} implementations are concise is because they use powerful higher order \gls{IOT} programming abstractions.
+For comprehensibility the simple temperature sensor from \cref{sec_t4t:mtasks} (\cref{lst_t4t:mtaskTemp}) is used to compare the expressive power of \gls{CLEAN} and \gls{PYTHON}-based \gls{IOT} programming abstractions.
+There are implementations for all four configurations: \gls{PRTS} (\gls{PYTHON} Raspberry Pi Temperature Sensor)\footnotemark, \gls{PWTS}\footnotemark[\value{footnote}]\todo{the dataset will be uploaded, the DOI is reserved.}
+\footnotetext{Lubbers, M.; Koopman, P.; Ramsingh, A.; Singer, J.; Trinder, P. (2021): Source code, line counts and memory stats for PRS, PWS, PRT and PWT.\ Zenodo.\ \href{https://doi.org/10.5281/zenodo.5081386}{10.5281/zenodo.5081386}.}, \gls{CRTS}\footnotemark{} and \gls{CWTS}\footnotemark[\value{footnote}] \todo{the dataset will be uploaded, the DOI is reserved.}
+\footnotetext{Lubbers, M.; Koopman, P.; Ramsingh, A.; Singer, J.; Trinder, P. (2021): Source code, line counts and memory stats for CRS, CWS, CRTS and CWTS.\ Zenodo.\ \href{https://doi.org/10.5281/zenodo.5040754}{10.5281/zenodo.5040754}.}
+but as the programming abstractions are broadly similar, we compare only the \gls{PWTS} and \gls{CWTS} implementations.
+
+Although the temperature sensor applications are small compared to the smart campus application, they share some typical \gls{IOT} stack traits.
+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).
+
+\begin{table}
+ \centering
+ \caption{Comparing \gls{CLEAN} and \gls{PYTHON} programming abstractions using the \gls{PWTS} and \gls{CWTS} temperature sensors (\gls{SLOC} and total number of files.)}%
+ \label{table_t4t:temp}
+ \begin{tabular}{llccl}
+ \toprule
+ Location & Functionality & \gls{PWTS} & \gls{CWTS} & Lines (\cref{lst_t4t:mtaskTemp})\\
+ \midrule
+ Sensor Node & Sensor Interface & 14 & 3 &~\ref{lst_t4t:mtaskTemp:si0},~\ref{lst_t4t:mtaskTemp:si1},~\ref{lst_t4t:mtaskTemp:si2}\\
+ & Sensor Node & 67 & 4 &~\ref{lst_t4t:mtaskTemp:sn0},~\ref{lst_t4t:mtaskTemp:sn1},~\ref{lst_t4t:mtaskTemp:sn2},~\ref{lst_t4t:mtaskTemp:sn3}\\
+ Server & Web Interface & 17 & 3 &~\ref{lst_t4t:mtaskTemp:wi0},~\ref{lst_t4t:mtaskTemp:wi1},~\ref{lst_t4t:mtaskTemp:wi2}\\
+ & Database Interface & 106 & 2 &~\ref{lst_t4t:mtaskTemp:di0},~\ref{lst_t4t:mtaskTemp:di1}\\
+ Communication & Communication & 94 & 3 &~\ref{lst_t4t:mtaskTemp:co0},~\ref{lst_t4t:mtaskTemp:co1},~\ref{lst_t4t:mtaskTemp:co2}\\
+ \midrule
+% \multicolumn{2}{c}{Total (\textnumero{} Files)} & 298 (27) & 15 (1) \\
+Total \gls{SLOC} & & 298 & 15 \\
+ \textnumero{} Files & & 27 & 1 \\
+ \bottomrule
+ \end{tabular}
+\end{table}
+
+The multiple tiers in \gls{PRS} and \gls{PWS} provide different levels of abstraction and separation of concerns.
+%in order to facilitate interoperation of the components.
+However, there are various ways that high-level abstractions make the \gls{CWS} much shorter than \gls{PRS} and \gls{PWS} implementations.
+
+Firstly, functional programming languages are generally more concise than most other programming languages because their powerful abstractions like higher-order and/or polymorphic functions require less code to describe a computation.
+Secondly, the \gls{TOP} paradigm used in \gls{ITASK} and \gls{MTASK} reduces the code size further by making it easy to specify \gls{IOT} functionality concisely.
+As examples, the step combinator \cleaninline{>>*.} allows the task value on the left-hand side to be observed until one of the steps is enabled;
+and the \cleaninline{viewSharedInformation} (line 31 of \cref{lst_t4t:mtaskTemp}) part of the UI will be automatically updated when the value of the \gls{SDS} changes. Moreover, each \gls{SDS} provides automatic updates to all coupled \glspl{SDS} and associated tasks. Thirdly, the amount of explicit type information is minimised in comparison to other languages, as much is automatically inferred~\cite{hughes1989functional}.
+
+\section{Could Tierless \texorpdfstring{\gls{IOT}}{IoT} Programming Be More Reliable than Tiered?}%
+\label{sec_t4t:Discussion}
+
+
+This section investigates whether tierless languages make \gls{IOT} programming more reliable. Arguably the much smaller and simpler code base is inherently more understandable, and more likely to be correct. Here we explore specific language issues, namely those of preserving type safety, maintainability, failure management, and community support.
+
+\subsection{Type Safety}%
+\label{sec_t4t:typesafety}
+Strong typing identifies errors early in the development cycle, and hence plays a crucial role in improving software quality. In consequence almost all modern languages provide strong typing, and encourage static typing to minimise runtime errors.
+% Phil: so widely known that a citation is unnecessary~\cite{madsen1990strong}.
+That said, many distributed system components written in languages that primarily use static typing, like \gls{HASKELL} and Scala, use some dynamic typing, e.g.\ to ensure that the data arriving in a message has the anticipated type~\cite{epstein2011towards,gupta2012akka}.
+
+In a typical tiered multi-language \gls{IOT} system the developer must integrate software in different languages with very different type systems, and potentially executing on different hardware. The challenges of maintaining type safety have long been recognised as a major component of the semantic friction in multi-language systems, e.g.\ \cite{ireland2009classification}.
+
+Even if the different languages used in two components are both strongly typed, they may attribute, often quite subtly, different types to a value. Such type errors can lead to runtime errors, or the application silently reporting erroneous data. Such errors can be hard to find. Automatic detection of such errors is sometimes possible, but requires an addition tool like Jinn~\cite{Jinn,Furr2005}.
+%Such errors can be hard to debug, partly because there is very limited tool support for detecting them
+%Phil: another possible source to discuss ~\cite{egyed1999automatically}
+
+\begin{lstPython}[caption={\Gls{PRS} loses type safety as a sensor node sends a {\tt\footnotesize double}, and the server stores a {\tt\footnotesize string}.},label={lst_t4t:float},morekeywords={message,enum,uint64,double}]
+message SensorData {
+ enum SensorType { TEMPERATURE = 1; [+\ldots+] }
+ SensorType sensor_type = 1;
+ uint64 timestamp = 2;
+ double float_value = 3;
+}
+[+\dotfill+]
+channel = 'sensor_status.%s.%s' % (hostname,
+ sensor_types.sensor_type_name(s.sensor_type))
+ self.r.publish(channel, s.SerializeToString())
+\end{lstPython}
+
+Analysis of the \gls{PRS} codebase reveals an instance where it, fairly innocuously, loses type safety. The fragment in \cref{lst_t4t:float} first shows a \pythoninline{double} sensor value being sent from the sensor node, and then shows the value being stored in Redis as a \pythoninline{string} on the server. As \gls{PWS} preserves the same server components it also suffers from the same loss of type safety.
+
+\emph{A tierless language makes it possible to guarantee type safety across an entire \gls{IOT} stack}. For example the \gls{CLEAN} compiler guarantees static type safety as the entire \gls{CWS} software stack is type checked, and generated, from a single source. Tierless web stack languages like Links~\cite{cooper2006links} and Hop~\cite{serrano2006hop} provide the same guarantee for web stacks.
+
+
+\subsection{Failure Management}%
+\label{sec_t4t:NetworkManagement}
+
+Some \gls{IOT} applications, including smart campus and other building monitoring applications, require high sensor uptimes. Hence, if a sensor or sensor node fails the application layer must be notified, so that it can report the failure. In the \gls{UOG} smart campus system a building manager is alerted to replace the failed device.
+
+In many \gls{IOT} architectures, including \gls{PRS} and \gls{PWS}, detecting failure is challenging because the application layer listens to the devices. When a device comes online, it registered with the application and starts sending data.
+When a device goes offline again, it could be because the power was out, the device was broken or the device just paused the connection.
+
+If a sensor node fails in \gls{CWS}, the \gls{ITASK}\slash\gls{MTASK} combinator interacting with a sensor node will throw an \gls{ITASK} exception.
+The exception is propagated and a handler can respond, e.g.\ rescheduling the task on a different device in the room, or requesting that a manager replaces the device. That is, \gls{ITASK}, uses standard succinct declarative exception handling.
+
+\begin{lstClean}[caption={An \gls{MTASK} failover combinator.},label={lst_t4t:failover}]
+failover :: [TCPSettings] (Main (MTask BCInterpret a)) -> Task a
+failover [] _ = throw "Exhausted device pool"
+failover [d:ds] mtask = try ( withDevice d (liftmTask mtask) ) except
+where except MTEUnexpectedDisconnect = failover ds mtask
+ except _ = throw e
+\end{lstClean}
+
+In the \gls{UOG} smart campus application, this can be done by creating a pool of sensor nodes for each room and when a sensor node fails, assign another one to the task.
+%If the pool of sensor nodes for a room is exhausted, contact a manager.
+\Cref{lst_t4t:failover} shows a failover combinator that executes an \gls{MTASK} on one of a pool of sensor nodes.
+If a sensor node unexpectedly disconnects, the next sensor node is tried until there are no sensor nodes left.
+If other errors occur they are propagated as usual.
+
+
+Currently, \gls{PRS} and \gls{PWS} both use heartbeats to confirm that the sensor nodes are operational, and will report failures. At the cost of extending the codebase, failover to an alternate sensor node could be provided.
+
+\subsection{Maintainability}
+
+Far more engineering effort is expended on maintaining a system, than on the initial development. Tiered and tierless \gls{IOT} systems have very different maintainability properties.
+
+The modularity of the tiered stack makes replacing tiers/components easy. For example in \gls{PWS} or \gls{PRS} the MongoDB NoSQL DBMS could be readily be replaced by an alternative like {CouchDB}. Because a tierless compiler must generate code for components, replacing them may not be so easy. If there are \gls{ITASK} abstractions for the component then replacement is straightforward. For example replacing SQLite with some other SQL DBMS simply entails recompilation of the application.
+However incorporating a component that does not yet have a task abstraction, like a NoSQL DBMS, is more involved. That is, a foreign function interface to the new component must be implemented, along with a suitable \gls{ITASK} abstraction for operations on the component.
+
+Many maintenance tasks are smaller in scale and occur within the components or tiers. Consider a simple change, for example if the temperature value recorded by a sensor changes from integer to real.
+
+All tiers of a tiered stack must be correctly and consistently refactored to reflect the change of temperature data type: so changes at the perception, network, application and presentation layers. A \gls{PWS} developer works in seven languages and two paradigms to effect the change (\cref{table_t4t:multi}), and must edit many source files. Many programming errors are either detected at runtime when testing the stack, or worse not automatically detected and produce erroneous results.
+
+In a tierless language the source code is much smaller and so it is easier to comprehend, i.e.\ to understand what refactoring is required. A \gls{CWS} developer works in only two languages and a single paradigm to effect the change, and will edit no more than three source files (\cref{table_t4t:multi}). Moreover, the compiler will statically detect many programming errors.
+
+More substantial in-component maintenance raises similar issues as for tiered implementations. If the maintenance activity requires a new task combinator, this is readily constructed in \gls{ITASK}, but may require changing the \gls{DSL} implementation in \gls{MTASK}, i.e.\ to change the compiler and the byte code interpreter. That is, \gls{MTASK} is more \emph{brittle} than \gls{ITASK}.
+
+In summary, while a tiered approach makes replacing components easy, refactoring within the components is far harder in a multi-tier multi-language \gls{IOT} implementation than in a tierless \gls{IOT} implementation.
+
+\subsection{Support}%
+\label{sec_t4t:support}
+%\mlcomment{I've shortened this quite a bit}
+Community and tool support are essential for engineering reliable production software. \gls{PRS} and \gls{PWS} are both \gls{PYTHON} based, and \gls{PYTHON}\slash\gls{MICROPYTHON} are among the most popular programming languages~\cite{cass2020top}. \gls{PYTHON} is also a common choice for some tiers of \gls{IOT} applications~\cite{tanganelli2015coapthon}.
+Hence, there are a wide range of development tools like \glspl{IDE} and debuggers, a thriving community and a wealth of training material. There are even specialised \gls{IOT} Boards like PyBoard \& WiPy that are specifically programmed using \gls{PYTHON} variations like \gls{MICROPYTHON}.
+
+In contrast, tierless languages are far less mature than the languages used in tiered stacks, and far less widely adopted.
+This means that for \gls{CWS} and \gls{CRS} there are fewer tools, a far smaller developer community, and less training material available.
+
+\Gls{CWS} and \gls{CRS} are both written in \glspl{DSL} embedded in \gls{CLEAN}, a fairly stable industrial-grade but niche functional programming language.
+The \glspl{DSL} are implemented in \gls{CLEAN} but require experimental compiler extensions that are often undocumented.
+There are few maintainers of the \glspl{DSL} and documentation is often sparse.
+Acquiring information about the systems requires distilling academic papers and referring to the source code.
+There is a \gls{CLEAN} \gls{IDE}, but it does not contain support for the \gls{ITASK} or \gls{MTASK} \glspl{DSL}.
+
+\section{Comparing Tierless Languages for Resource-rich/constrained Sensor Nodes}%
+\label{sec_t4t:ComparingTierless}
+
+This section compares two tierless \gls{IOT} languages: one for resource-rich, and the other for resource-constrained, sensor nodes. Key issues are the extent to which the very significant resource constraints of a microcontroller limit the language, and the benefits of executing on bare metal, i.e.\ without an \gls{OS}.
+
+With the tierless \gls{CLEAN} technologies described here, \gls{ITASK} are always used to program the application and presentation layers of the \gls{IOT} stack. So any differences occur in the perception and network layer programming.
+If sensor nodes have the capacity to support \gls{ITASK}, a tierless \gls{IOT} system can be constructed in \gls{CLEAN} using only \gls{ITASK}, as in \gls{CRS}. Alternatively for sensor nodes with low computational power, like typical microcontrollers, \gls{MTASK} is used for the perception and network layers, as in \gls{CWS}.
+This section compares the \gls{ITASK} and \gls{MTASK} \glspl{EDSL}, with reference to \gls{CRS} and \gls{CWS} as exemplars. \Cref{table_t4t:languagecomparison} summarises the differences between the \gls{CLEAN} embedded \gls{IOT} \glspl{EDSL} and their host language.
+
+\begin{table}
+ \small
+ \caption{Comparing tierless \gls{IOT} languages for resource-rich sensor nodes (\gls{ITASK} \gls{EDSL}), for resource-constrained sensor nodes (\gls{MTASK} \gls{EDSL}), and their \gls{CLEAN} host language.}%
+ \label{table_t4t:languagecomparison}
+ \begin{tabularx}{\textwidth}{lXXX}
+ \toprule
+ Property & \gls{CLEAN} & \gls{ITASK} & \gls{MTASK}\\
+ \midrule
+ Function for an \gls{IOT} System & Host Language & Specify distributed workflows & Specify sensor node workflow \\
+ \midrule
+ Referentially transparent & Yes & Yes & Yes \\
+ Evaluation strategy & Lazy & Lazy & Strict\\
+ Higher-order functions & Yes & Yes & No \\
+ User-defined datatypes & Yes & Yes & No \\
+ Task oriented & No & Yes & Yes \\
+ Higher-order tasks & {--} & Yes & No \\
+ Execution Target & Commodity PC & Commodity PC and Browser & Microcontroller\\
+ Language Implementation & Compiled or interpreted & Compiled and interpreted & Interpreted\\
+ \bottomrule
+ \end{tabularx}
+\end{table}
+
+\subsection{Language Restrictions for Resource-Constrained Execution}
+
+Executing components on a resource-constrained sensor node imposes restrictions on programming abstractions available in a tierless \gls{IOT} language or \gls{DSL}. The small and fixed-size memory are key limitations. The limitations are shared by any high-level language that targets microcontrollers such as BIT, PICBIT, PICOBIT, Microscheme and uLisp~\cite{dube_bit:_2000,feeley_picbit:_2003,st-amour_picobit:_2009,suchocki_microscheme:_2015, johnson-davies_lisp_2020}.
+Even in low level languages some language features are disabled by default when targeting microcontrollers, such as runtime type information (RTTI) in \gls{CPP}.
+
+Here we investigate the restrictions imposed by resource-constrained sensor nodes on \gls{MTASK}, in comparison with \gls{ITASK}. While \gls{ITASK} and \gls{MTASK} are by design superficially similar languages, to execute on resource-constrained sensor nodes \gls{MTASK} tasks are more restricted, and have a different semantics.
+
+\Gls{MTASK} programs do not support user defined higher order functions, the only higher order functions available are the predefined \gls{MTASK} combinators.
+Programmers can, however, use any construct of the \gls{CLEAN} host language to construct an \gls{MTASK} program, including higher order functions and arbitrary data types. For example folding an \gls{MTASK} combinator over a list of tasks.
+The only restriction is that any higher order function must be macro expanded to a first order \gls{MTASK} program before being compiled to byte code.
+%\mlcomment{Pieter: Refine paragraph about macro expansion and currying/HOF}
+As an example in \cref{lst_t4t:mtaskTemp} we use \cleaninline{temperature dht >>~.} \cleaninline{setSds localSds} instead of \cleaninline{temperature dht >>~.} \cleaninline{\\temp -> setSds localSds temp}.
+%However, this is limited to situations where the expressions are expanded to the required \gls{MTASK} types, i.e.\ the host language acts as a macro language for \gls{MTASK}.
+%\mlcomment{I've refined this. The host language does not offer limited use of HOF and currying. It only appears to offer, just macro expansion}.
+%\pwtcomment{I've rewritten: please check.}
+
+In contrast to \gls{ITASK}, \gls{MTASK} programs have no user defined or recursive data types. It is possible to add user defined types---as long as they are not sum types---to \gls{MTASK}, but this requires significant programming effort.
+Due to the language being shallowly embedded, pattern matching and field selection on user defined types is not readily available and thus needs to be built into the language by hand.
+Alleviating this limitation remains future work.
+
+\Gls{MTASK} programs mainly use strict rather than lazy evaluation to minimise the requirement for a variable size heap. This has no significant impact for the \gls{MTASK} programs we have developed here, nor in other \gls{IOT} applications we have engineered.
+
+\Gls{MTASK} abstractions are less easily extended than \gls{ITASK}. For example \gls{ITASK} can be extended with a new combinator that composes a specific set of tasks for some application.
+Without higher order functions the equivalent combinator can often not be expressed in \gls{MTASK}, and adding it to \gls{MTASK} requires extending the \gls{DSL} rather than writing a new definition in it.
+On the other hand, it is possible to outsource this logic to the \gls{ITASK} program as \gls{MTASK} and \gls{ITASK} tasks are so tightly integrated.
+
+\subsection{The Benefits of a Bare Metal Execution Environment}
+
+Despite the language restrictions, components of a tierless language executing on a microcontroller can exploit the bare metal environment. Many of these benefits are shared by other bare metal languages like \gls{MICROPYTHON} or \gls{C}\slash\gls{CPP}. So as \gls{MTASK} executes on bare metal it has some advantages over \gls{ITASK}. Most notably \gls{MTASK} has better control of timing as on bare metal there are no other processes or threads that compete for CPU cycles.
+This makes the \gls{MTASK} \cleaninline{repeatEvery} (\cref{lst_t4t:mtaskTemp}, \cref{lst_t4t:mtaskTemp:sn2}) much more accurate than the \gls{ITASK} \cleaninline{waitForTimer} (\cref{lst_t4t:itaskTempFull}, \cref{lst_t4t:itaskTempFull:waitForTimer}).
+While exact timing is not important in this example, it is significant for many other \gls{IOT} applications.
+In contrast \gls{ITASK} cannot give real time guarantees. One reason is that an \gls{ITASK} server can ship an arbitrary number of \gls{ITASK} or \gls{MTASK} tasks to a device.
+Such competing tasks, or indeed other \gls{OS} threads and processes, consume processor time and reduce the accuracy of timings.
+However, even when using multiple \gls{MTASK} tasks, it is easier to control the number of tasks on a device than controlling the number of processes and threads executing under an \gls{OS}.
+
+An \gls{MTASK} program has more control over energy consumption.
+The \gls{MTASK} \gls{EDSL} and the \gls{MTASK} \gls{RTS} are designed to minimise energy usage~\cite{crooijmans_reducing_2021}.
+Intensional analysis of the declarative task description and current progress at run time allow the \gls{RTS} to schedule tasks and maximise idle time.
+As the \gls{RTS} is the only program running on the device, it can enforce deep sleep and wake up without having to worry about influencing other processes.
+
+The \gls{MTASK} \gls{RTS} has direct control of the peripherals attached to the microcontroller, e.g.\ over \gls{GPIO} pins. There is no interaction with, or permission required from, the \gls{OS}.
+Moreover, microcontrollers typically have better support for hardware interrupts, reducing the need to poll peripherals.
+The downside of this direct control is that \gls{CWS} has to handle some exceptions that would otherwise be handled by the \gls{OS} in \gls{CRS} and hence the device management code is longer: 28 versus 20 \gls{SLOC} in \cref{table_t4t:multi}.
+
+\subsection{Summary}
+
+\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~\cite{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}
+
+\subsection{Summary}
+
+
+We have conducted a systematic comparative evaluation of two tierless language technologies for \gls{IOT} stacks: one for resource-rich, and the other for resource-constrained sensor nodes. The basis is four implementations of a deployed smart campus \gls{IOT} stack: two conventional tiered and \gls{PYTHON}-based stacks, and two tierless \gls{CLEAN} stacks. An operational comparison of implementations demonstrates that they have equivalent functionality, and meet the \gls{UOG} smart campus functional requirements (\cref{sec_t4t:Case}).
+
+We show that \emph{tierless languages have the potential to significantly reduce the development effort for \gls{IOT} systems}. Specifically the tierless \gls{CWS} and \gls{CRS} stacks require far less code, i.e.\ 70\% fewer \gls{SLOC}, than the tiered \gls{PWS} and \gls{PRS} stacks (\cref{table_t4t:multi}). We analyse the code reduction and attribute it to the following three main factors.
+\begin{enumerate*}
+ \item Tierless developers need to manage less interoperation: \gls{CRS} uses a single \gls{DSL} and paradigm, and \gls{CWS} uses two \glspl{DSL} in a single paradigm and three source code files. In contrast, both \gls{PRS} and \gls{PWS} use at least six languages in two paradigms and spread over at least 35 source code files (\cref{table_t4t:multi,table_t4t:languages,table_t4t:paradigms}). Thus, a tierless stack minimises semantic friction.
+ \item Tierless developers benefit from automatically generated, and hence correct, communication (\cref{lst_t4t:mtaskTemp}), and write 6$\times$ less communication code (\cref{fig_t4t:multipercentage}).
+%and TODO).%~\ref{lst_t4t:mqtt}).
+ \item Tierless developers can exploit powerful high-level declarative and task-oriented \gls{IOT} programming abstractions (\cref{table_t4t:temp}), specifically the composable, higher-order task combinators outlined in \cref{sec_t4t:itasks}.
+Our empirical results for \gls{IOT} systems are consistent with the benefits claimed for tierless languages in other application domains. Namely that a tierless language provides a \textit{Higher Abstraction Level}, \textit{Improved Software Design}, and improved \textit{Program Comprehension}~\cite{weisenburger2020survey}.
+\end{enumerate*}
+
+We show that \emph{tierless languages have the potential to significantly improve the reliability of \gls{IOT} systems}. We illustrate how \gls{CLEAN} maintains type safety, contrasting this with a loss of type safety in \gls{PRS}.
+We illustrate higher order failure management in \gls{CLEAN}\slash\gls{ITASK}/\gls{MTASK} in contrast to the \gls{PYTHON}-based failure management in \gls{PRS}. For maintainability a tiered approach makes replacing components easy, but refactoring within the components is far harder than in a tierless \gls{IOT} language. Again our findings are consistent with the simplied \textit{Code Maintenance} benefits claimed for tierless languages~\cite{weisenburger2020survey}.
+Finally, we contrast community support for the technologies (\cref{sec_t4t:Discussion}).
+
+%\pwtcomment{Pieter: please check discussion of ~\cite{weisenburger2020survey} in preceding 2 paragraphs}
+
+We report \emph{the first comparison of a tierless \gls{IOT} codebase for resource-rich sensor nodes with one for resource-constrained sensor nodes}.
+\begin{enumerate*}
+ \item The tierless implementations have very similar code sizes (\gls{SLOC}), as do the tiered implementations: less than 7\% difference in \cref{table_t4t:multi}. This suggests that the development and maintenance effort of simple tierless \gls{IOT} systems for resource-constrained and for resource-rich sensor nodes is similar, as it is for tiered technologies.
+ \item The percentages of code required to implement each \gls{IOT} functionality in the tierless \gls{CLEAN} implementations is very similar
+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 microcontroller restricts the programming abstractions available in \gls{MTASK} to a fixed set of combinators, no user defined or recursive data types, strict evaluation, and makes it harder to add new abstractions. Even with these restrictions \gls{MTASK} provide a higher level of abstraction than most bare metal languages, and can readily express many \gls{IOT} applications including the \gls{CWS} \gls{UOG} smart campus application (\cref{sec_t4t:ComparingTierless}).
+Our empirical results are consistent with the benefits of tierless languages listed in Section 2.1 of~\cite{weisenburger2020survey}.
+
+\subsection{Reflections}
+
+This study is based on a specific pair of tierless \gls{IOT} languages, and the \gls{CLEAN} language frameworks represent a specific set of tierless language design decisions. Many alternative tierless \gls{IOT} language designs are possible, and some are outlined in \cref{sec_t4t:characteristics}. Crucially the limitations of the tierless \gls{CLEAN} languages, e.g.\ that they currently provide limited security, should not be seen as limitations of tierless technologies in general.
+
+This study has explored some, but not all, of the potential benefits of tierless languages for \gls{IOT} systems. An \gls{IOT} system specified as a single tierless program is amenable to a host of programming language technologies. For example, if the language has a formal semantics, as Links, Hop and \gls{CLEAN} tasks do~\cite{cooper2006links,serrano2006hop,plasmeijer_task-oriented_2012}, it is possible to prove properties of the system, e.g.\ \cite{Steenvoorden2019tophat}. As another example program analyses can be applied, and \cref{sec_t4t:characteristics} and~\cite{weisenburger2020survey} outline some of the analyses could be, and in some cases have been, used to improve \gls{IOT} systems. Examples include automatic tier splitting~\cite{10.1145/2661136.2661146}, and controlling information flow to enhance security~\cite{valliappan_towards_2020}.
+
+While offering real benefits for \gls{IOT} systems development, tierless languages also raise some challenges. Programmers must master new tierless programming abstractions, and the semantics of these automatic multi-tier behaviours are necessarily relatively complex. In the \gls{CLEAN} context this entails becoming proficient with the \gls{ITASK} and \gls{MTASK} \glspl{DSL}. Moreover, specifying a behaviour that is not already provided by the tierless language requires either a workaround, or extending a \gls{DSL}. However, implementing the relatively simple smart campus application required no such adaption. Finally, tierless \gls{IOT} technology is very new, and both tool and community support have yet to mature.
+
+
+\subsection{Future Work}
+
+This paper is a technology comparison between tiered and tierless technologies. The metrics reported, such as code size, numbers of source code files, and of paradigms are only indirect, although widely accepted, measures of development effort. A more convincing evaluation of tierless technologies could be provided by conducting a carefully designed and substantial user study, e.g.\ using N-version programming.
+
+A study that implemented common benchmarks or a case study in multiple tierless \gls{IOT} languages would provide additional evidence for the generality of the tierless approach. Such a study would enable the demonstration and comparison of alternative design decisions within tierless languages, as outlined in \cref{sec_t4t:characteristics}.
+
+
+In ongoing work we are extending the \gls{MTASK} system in various ways. One extension allows \gls{MTASK} tasks to communicate directly, rather than via the \gls{ITASK} server. Another provides better energy management, which is crucial for battery powered sensor nodes.
+
+\section*{Acknowledgements}
+Thanks to Kristian Hentschel and Dejice Jacob who developed and maintain \gls{PRS}
+and to funders: Royal Netherlands Navy, the Radboud-Glasgow Collaboration Fund, and UK EPSRC grants MaRIONet (EP/P006434) and STARDUST (EP/T014628). We also thank Lito Michala, Jose Cano, Greg Michaelson, Rinus Plasmeijer, and the anonymous TIOT reviewers for valuable feedback on the paper.
\input{subfilepostamble}
\end{document}
--- /dev/null
+@article{sethi2017internet,
+ title={Internet of things: architectures, protocols, and applications},
+ author={Sethi, Pallavi and Sarangi, Smruti R},
+ journal={Journal of Electrical and Computer Engineering},
+ volume={2017},
+ year={2017},
+ publisher={Hindawi}
+}
+
+@inproceedings{muccini2018iot,
+author="Muccini, Henry and Moghaddam, Mahyar Tourchi",
+editor="Cuesta, Carlos E. and Garlan, David and P{\'e}rez, Jennifer",
+title="IoT Architectural Styles",
+booktitle="Software Architecture",
+year="2018",
+publisher="Springer International Publishing",
+address="Cham",
+pages="68--85",
+abstract="IoT components are becoming more and more ubiquitous. Thus, the necessity of architecting IoT applications is bringing a substantial attention towards software engineering community. On this occasion, different styles and patterns can facilitate shaping the IoT architectural characteristics. This study aims at defining, identifying, classifying, and re-designing a class of IoT styles and patterns at the architectural level. Conforming a systematic mapping study (SMS) selection procedure, we picked out 63 papers among over 2,300 candidate studies. To this end, we applied a rigorous classification and extraction framework to select and analyze the most influential domain-related information. Our analysis revealed the following main findings: (i) facing by various architectural styles that attempted to address various aspects of IoT systems, cloud and fog are discerned as their most important components. (ii) distributed patterns are not widely discussed for IoT architecture, however, there is foreseen a grow specially for their industrial applications. (iii) starting from the last few years on, there is still a growing scientific interest on IoT architectural styles. This study gives a solid foundation for classifying existing and future approaches for IoT styles beneficial for academic and industrial researchers. It provides a set of abstract IoT reference architectures to be applicable on various architectural styles.",
+isbn="978-3-030-00761-4"
+}
+
+@inproceedings{rosenberg1997some,
+ title={Some misconceptions about lines of code},
+ author={Rosenberg, Jarrett},
+ booktitle={Proceedings fourth international software metrics symposium},
+ pages={137--142},
+ year={1997},
+ organization={IEEE},
+ publisher={IEEE},
+ doi={10.1109/METRIC.1997.637174},
+address={Albuquerque, NM, USA}
+}
+
+@inproceedings{cooper2006links,
+ address = {Berlin, Heidelberg},
+ title = {Links: {Web} {Programming} {Without} {Tiers}},
+ isbn = {978-3-540-74792-5},
+ abstract = {Links is a programming language for web applications that generates code for all three tiers of a web application from a single source, compiling into JavaScript to run on the client and into SQL to run on the database. Links supports rich clients running in what has been dubbed `Ajax' style, and supports concurrent processes with statically-typed message passing. Links is scalable in the sense that session state is preserved in the client rather than the server, in contrast to other approaches such as Java Servlets or PLT Scheme. Client-side concurrency in JavaScript and transfer of computation between client and server are both supported by translation into continuation-passing style.},
+ booktitle = {Formal {Methods} for {Components} and {Objects}},
+ publisher = {Springer Berlin Heidelberg},
+ author = {Cooper, Ezra and Lindley, Sam and Wadler, Philip and Yallop, Jeremy},
+ editor = {de Boer, Frank S. and Bonsangue, Marcello M. and Graf, Susanne and de Roever, Willem-Paul},
+ year = {2007},
+ pages = {266--296}
+}
+
+@inproceedings{serrano2006hop,
+ title={Hop: a language for programming the web 2.0},
+ author={Serrano, Manuel and Gallesio, Erick and Loitsch, Florian},
+ booktitle={OOPSLA Companion},
+ pages={975--985},
+ year={2006},
+ publisher={ACM},
+ address={Portland, Oregon, USA},
+}
+
+@inproceedings{lloyd1994practical,
+ title={Practical Advtanages of Declarative Programming.},
+ author={Lloyd, John W},
+ booktitle={GULP-PRODE (1)},
+ pages={18--30},
+ year={1994}
+}
+
+@online{singer16,
+author ={Jeremy Singer, Dejice Jacob, Kristian Hentschel},
+year = {2016},
+title ={Anyscale Sensors},
+url ={https://bitbucket.org/jsinger/anyscale-sensors/src/master/Readme.md},
+month ={Apr},
+lastaccessed ={April 1, 2016},
+}
+
+@article{pechtchanski2005immutability,
+ title={Immutability specification and its applications},
+ author={Pechtchanski, Igor and Sarkar, Vivek},
+ journal={Concurrency and Computation: Practice and Experience},
+ volume={17},
+ number={5-6},
+ pages={639--662},
+ year={2005},
+ publisher={Wiley Online Library}
+}
+
+@inproceedings{steiner_firmata_2009,
+ title = {Firmata: {Towards} {Making} {Microcontrollers} {Act} {Like} {Extensions} of the {Computer}.},
+ booktitle = {{NIME}},
+ author = {Steiner, Hans-Christoph},
+ year = {2009},
+ pages = {125--130},
+}
+
+@article{levis_mate_2002,
+ title = {Maté: {A} tiny virtual machine for sensor networks},
+ volume = {37},
+ number = {10},
+ journal = {ACM Sigplan Notices},
+ author = {Levis, Philip and Culler, David},
+ year = {2002},
+ publisher = {ACM},
+ pages = {85--95},
+ file = {Levis and Culler - Matd A Tiny Virtual Machine for Sensor Networks.pdf:/home/mrl/.local/share/zotero/storage/RMPGY9NI/Levis and Culler - Matd A Tiny Virtual Machine for Sensor Networks.pdf:application/pdf}
+}
+
+@inproceedings{grebe_threading_2019,
+ address = {Cham},
+ title = {Threading the {Arduino} with {Haskell}},
+ isbn = {978-3-030-14805-8},
+ abstract = {Programming embedded microcontrollers often requires the scheduling of independent threads of execution, specifying the interaction and sequencing of actions in the multiple threads. Developing and debugging such multi-threaded systems can be especially challenging in highly resource constrained systems such as the Arduino line of microcontroller boards. The Haskino library, developed at the University of Kansas, allows programmers to develop code for Arduino-based microcontrollers using monadic Haskell program fragments. This paper describes our efforts to extend the Haskino library to translate monadic Haskell code to multi-threaded code executing on Arduino boards.},
+ booktitle = {Trends in {Functional} {Programming}},
+ publisher = {Springer},
+ author = {Grebe, Mark and Gill, Andy},
+ editor = {Van Horn, David and Hughes, John},
+ year = {2019},
+ pages = {135--154},
+ file = {Grebe and Gill - Threading the Arduino with Haskell.pdf:/home/mrl/.local/share/zotero/storage/DW5PS9ZA/Grebe and Gill - Threading the Arduino with Haskell.pdf:application/pdf}
+}
+
+@inproceedings{grebe_haskino_2016,
+ title = {Haskino: {A} remote monad for programming the arduino},
+ shorttitle = {Haskino},
+ booktitle = {International {Symposium} on {Practical} {Aspects} of {Declarative} {Languages}},
+ publisher = {Springer},
+ author = {Grebe, Mark and Gill, Andy},
+ year = {2016},
+ pages = {153--168},
+ file = {Grebe-16-Haskino.pdf:/home/mrl/.local/share/zotero/storage/ABG7TTLV/Grebe-16-Haskino.pdf:application/pdf}
+}
+
+@inproceedings{gill_remote_2015,
+author = {Gill, Andy and Sculthorpe, Neil and Dawson, Justin and Eskilson, Aleksander and Farmer, Andrew and Grebe, Mark and Rosenbluth, Jeffrey and Scott, Ryan and Stanton, James},
+title = {The Remote Monad Design Pattern},
+year = {2015},
+doi = {10.1145/2804302.2804311},
+booktitle = {Proceedings of the 2015 ACM SIGPLAN Symposium on Haskell},
+pages = {59–70},
+}
+
+@article{light2017mosquitto,
+ title={Mosquitto: server and client implementation of the MQTT protocol},
+ author={Light, Roger},
+ journal={Journal of Open Source Software},
+ volume={2},
+ number={13},
+ pages={265},
+ year={2017}
+}
+
+@article{adl2006compiler,
+ title={Compiler and runtime support for efficient software transactional memory},
+ author={Adl-Tabatabai, Ali-Reza and Lewis, Brian T and Menon, Vijay and Murphy, Brian R and Saha, Bratin and Shpeisman, Tatiana},
+ journal={ACM SIGPLAN Notices},
+ volume={41},
+ number={6},
+ pages={26--37},
+ year={2006},
+ publisher={ACM}
+}
+
+@inproceedings{schwarz2002disassembly,
+ title={Disassembly of executable code revisited},
+ author={Schwarz, Benjamin and Debray, Saumya and Andrews, Gregory},
+ booktitle={Ninth Working Conference on Reverse Engineering, 2002. Proceedings.},
+ pages={45--54},
+ year={2002},
+ organization={IEEE}
+}
+
+@article{hughes1989functional,
+ title={Why functional programming matters},
+ author={Hughes, John},
+ journal={The computer journal},
+ volume={32},
+ number={2},
+ pages={98--107},
+ year={1989},
+ publisher={Oxford University Press}
+}
+
+@article{davidson2018expressiveness,
+ title={Expressiveness, meanings and machines},
+ author={Davidson, Joe and Michaelson, Greg},
+ journal={Computability},
+ volume={7},
+ number={4},
+ pages={367--394},
+ year={2018},
+ publisher={IOS Press}
+}
+
+@inproceedings{troyer_building_2018,
+ title = {Building {IoT} {Systems} {Using} {Distributed} {First}-{Class} {Reactive} {Programming}},
+ booktitle = {2018 {IEEE} {International} {Conference} on {Cloud} {Computing} {Technology} and {Science} ({CloudCom})},
+ author = {Troyer, de, Christophe and Nicolay, Jens and Meuter, de, Wolfgang},
+ month = dec,
+ year = {2018},
+ pages = {185--192},
+ publisher = {IEEE},
+ address = {Nicosia, Cyprus},
+}
+
+@article{harth_predictive_2018,
+ author = {Natascha Harth and Christos Anagnostopoulos and Dimitrios Pezaros},
+ title = {Predictive intelligence to the edge: impact on edge analytics},
+ journal = {Evolving Systems},
+ volume = {9},
+ number = {2},
+ pages = {95--118},
+ year = {2018},
+}
+
+@inproceedings{naik2017choice,
+ title={Choice of effective messaging protocols for IoT systems: MQTT, CoAP, AMQP and HTTP},
+ author={Naik, Nitin},
+ booktitle={2017 IEEE international systems engineering symposium (ISSE)},
+ pages={1--7},
+ year={2017},
+ organization={IEEE}
+}
+
+@book{guinard_building_2016,
+ address = {USA},
+ edition = {1st},
+ title = {Building the {Web} of {Things}: {With} {Examples} in {Node}.{Js} and {Raspberry} {Pi}},
+ isbn = {1-61729-268-0},
+ publisher = {Manning Publications Co.},
+ author = {Guinard, Dominique and Trifa, Vlad},
+ year = {2016}
+}
+
+@inproceedings{ireland2009classification,
+ title={A classification of object-relational impedance mismatch},
+ author={Ireland, Christopher and Bowers, David and Newton, Michael and Waugh, Kevin},
+ booktitle={2009 First International Confernce on Advances in Databases, Knowledge, and Data Applications},
+ pages={36--43},
+ year={2009},
+ organization={IEEE},
+ publisher={IEEE},
+ doi={10.1109/DBKDA.2009.11},
+ address={Gosier, France}
+}
+
+@article{maccormack2007impact,
+ title={The impact of component modularity on design evolution: Evidence from the software industry},
+ author={MacCormack, Alan and Rusnak, John and Baldwin, Carliss Y},
+ journal={Harvard Business School Technology \& Operations Mgt. Unit Research Paper},
+ number={038},
+ volume={08},
+ year={2007},
+ month={dec},
+ doi={10.2139/ssrn.1071720},
+}
+
+
+@inproceedings{belle2013layered,
+ address = {Boston, MA, USA},
+ title = {The layered architecture revisited: {Is} it an optimization problem?},
+ volume = {1},
+ isbn = {978-1-5108-4159-8},
+ shorttitle = {{SEKE} 2013},
+ booktitle = {Proceedings of the {Twenty}-{Fifth} {International} {Conference} on {Software} {Engineering} \& {Knowledge} {E}},
+ publisher = {KSI Research Inc},
+ author = {Belle, Alvine Boaye and El-Boussaidi, Ghizlane and Desrosiers, Christian and Mili, Hafedh},
+ year = {2013},
+ pages = {344--349}
+}
+
+@inproceedings{lee2001component,
+ title={Component identification method with coupling and cohesion},
+ author={Lee, Jong Kook and Jung, Seung Jae and Kim, Soo Dong and Jang, Woo Hyun and Ham, Dong Han},
+ booktitle={Proceedings Eighth Asia-Pacific Software Engineering Conference},
+ pages={79--86},
+ year={2001},
+ organization={IEEE},
+ publisher={IEEE},
+ address={Macao, China},
+}
+
+@article{antoniu2007combining,
+ title={Combining data sharing with the master--worker paradigm in the common component architecture},
+ author={Antoniu, Gabriel and Bouziane, Hinde Lilia and Jan, Mathieu and P{\'e}rez, Christian and Priol, Thierry},
+ journal={Cluster Computing},
+ volume={10},
+ number={3},
+ pages={265--276},
+ year={2007},
+ publisher={Springer}
+}
+
+@inproceedings{grgic2016web,
+ title={A web-based IoT solution for monitoring data using MQTT protocol},
+ author={Grgi{\'c}, Kre{\v{s}}imir and {\v{S}}peh, Ivan and He{\dj}i, Ivan},
+ booktitle={2016 international conference on smart systems and technologies (SST)},
+ pages={249--253},
+ year={2016},
+ organization={IEEE}
+}
+
+@inproceedings{athanasopoulos2006interoperability,
+ title={Interoperability among heterogeneous services},
+ author={Athanasopoulos, George and Tsalgatidou, Aphrodite and Pantazoglou, Michael},
+ booktitle={2006 IEEE International Conference on Services Computing (SCC'06)},
+ pages={174--181},
+ year={2006},
+ organization={IEEE}
+}
+
+@article{mazzei2018full,
+ title={A full stack for quick prototyping of IoT solutions},
+ author={Mazzei, Daniele and Baldi, Giacomo and Montelisciani, Gabriele and Fantoni, Gualtiero},
+ journal={Annals of Telecommunications},
+ volume={73},
+ number={7-8},
+ pages={439--449},
+ year={2018},
+ publisher={Springer}
+}
+
+@article{barrett2015fine,
+ title={Fine-grained language composition: A case study},
+ author={Barrett, Edd and Bolz, Carl Friedrich and Diekmann, Lukas and Tratt, Laurence},
+ journal={arXiv preprint arXiv:1503.08623},
+ year={2015}
+}
+
+@inproceedings{patwardhan2004communication,
+ title={Communication breakdown: analyzing cpu usage in commercial web workloads},
+ author={Patwardhan, Jaidev P and Lebeck, Alvin R and Sorin, Daniel J},
+ booktitle={IEEE International Symposium on-ISPASS Performance Analysis of Systems and Software, 2004},
+ pages={12--19},
+ year={2004},
+ organization={IEEE}
+}
+
+@inproceedings{cooper2008essence,
+ title={The essence of form abstraction},
+ author={Cooper, Ezra and Lindley, Sam and Wadler, Philip and Yallop, Jeremy},
+ booktitle={Asian Symposium on Programming Languages and Systems},
+ pages={205--220},
+ year={2008},
+ organization={Springer}
+}
+
+@article{rinard2003credible,
+ title={Credible compilation},
+ author={Rinard, Martin C},
+ year={2003}
+}
+
+@inproceedings{bucur2014prototyping,
+ title={Prototyping symbolic execution engines for interpreted languages},
+ author={Bucur, Stefan and Kinder, Johannes and Candea, George},
+ booktitle={Proceedings of the 19th international conference on Architectural support for programming languages and operating systems},
+ pages={239--254},
+ year={2014}
+}
+
+@inproceedings{barany2014python,
+ title={Python interpreter performance deconstructed},
+ author={Barany, Gerg{\"o}},
+ booktitle={Proceedings of the Workshop on Dynamic Languages and Applications},
+ pages={1--9},
+ year={2014}
+}
+
+@article{mayer2017multi,
+ title={On multi-language software development, cross-language links and accompanying tools: a survey of professional software developers},
+ author={Mayer, Philip and Kirsch, Michael and Le, Minh Anh},
+ journal={Journal of Software Engineering Research and Development},
+ volume={5},
+ number={1},
+ pages={1},
+ year={2017},
+ publisher={Springer}
+}
+
+@inproceedings{mayer2015empirical,
+author = {Mayer, Philip and Bauer, Alexander},
+title = {An Empirical Analysis of the Utilization of Multiple Programming Languages in Open Source Projects},
+year = {2015},
+isbn = {9781450333504},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/2745802.2745805},
+doi = {10.1145/2745802.2745805},
+abstract = {Background: Anecdotal evidence suggests that software applications are usually implemented using a combination of (programming) languages. Aim: We want to provide empirical evidence on the phenomenon of multi-language programming. Methods: We use data mining of 1150 open source projects selected for diversity from a public repository to a) investigate the projects for number and type of languages found and the relative sizes of the languages; b) report on associations between the number of languages found and the size, age, number of contributors, and number of commits of a project using a (Quasi-)Poisson regression model, and c) discuss concrete associations between the general-purpose languages and domain-specific languages found using frequent item set mining. Results: We found a) a mean number of 5 languages per project with a clearly dominant main general-purpose language and 5 often-used DSL types, b) a significant influence of the size, number of commits, and the main language on the number of languages as well as no significant influence of age and number of contributors, and c) three language ecosystems grouped around XML, Shell/Make, and HTML/CSS. Conclusions: Multi-language programming seems to be common in open-source projects and is a factor which must be dealt with in tooling and when assessing development and maintenance of such software systems.},
+booktitle = {Proceedings of the 19th International Conference on Evaluation and Assessment in Software Engineering},
+articleno = {4},
+numpages = {10},
+location = {Nanjing, China},
+series = {EASE '15}
+}
+
+@article{avizienis85n,
+ author={A. {Avizienis}},
+ journal={IEEE Transactions on Software Engineering},
+ title={The N-Version Approach to Fault-Tolerant Software},
+ year={1985},
+ volume={SE-11},
+ number={12},
+ pages={1491-1501},
+ doi={10.1109/TSE.1985.231893}
+}
+
+
+@inproceedings{motta2018challenges,
+author = {Motta, Rebeca C. and de Oliveira, K\'{a}thia M. and Travassos, Guilherme H.},
+title = {On Challenges in Engineering IoT Software Systems},
+year = {2018},
+isbn = {9781450365031},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/3266237.3266263},
+doi = {10.1145/3266237.3266263},
+abstract = {Contemporary software systems, such as the Internet of Things (IoT), Industry 4.0, and Smart Cities are new technology paradigms that offer challenges for their construction since they are calling into question our traditional form of developing software. They are a promising paradigm for the integration of devices and communications technologies. It is leading to a shift from the classical monolithic view of development where stakeholder receive a software product at the end (that we have been doing for decades), to software systems materialized through physical objects interconnected by networks and with embedded software to support daily activities. We need therefore to revisit our way of developing software systems and start to consider the particularities required by these new sorts of applications. This paper presents research toward the definition of a framework to support the systems engineering of IoT applications, where we evolved the Zachman's Framework as an alternative to the organization of this architecture. The activities were two folded to address this goal: a) we identified leading concerns of IoT applications, recovered from technical literature, practitioners and a Government Report, in different studies; b) we structured the IoT paradigm in different facets. These activities provided 14 significant concerns and seven facets that together represent the engineering challenges to be faced both by research and practice towards the advancement of IoT in practice.},
+booktitle = {Proceedings of the XXXII Brazilian Symposium on Software Engineering},
+pages = {42–51},
+numpages = {10},
+keywords = {challenges, concerns, internet of things, IoT, literature review, empirical software engineering},
+location = {Sao Carlos, Brazil},
+series = {SBES '18}
+}
+
+@article{gubbi2013internet,
+ title={Internet of Things (IoT): A vision, architectural elements, and future directions},
+ author={Gubbi, Jayavardhana and Buyya, Rajkumar and Marusic, Slaven and Palaniswami, Marimuthu},
+ journal={Future generation computer systems},
+ volume={29},
+ number={7},
+ pages={1645--1660},
+ year={2013},
+ publisher={Elsevier}
+}
+
+@article{guzman2018human,
+ title={What is human-machine communication, anyway},
+ author={Guzman, Andrea L},
+ journal={Human-machine communication: Rethinking communication, technology, and ourselves},
+ pages={1--28},
+ year={2018},
+ publisher={Peter Lang New York}
+}
+
+@article{wan2016software,
+ title={Software-defined industrial internet of things in the context of industry 4.0},
+ author={Wan, Jiafu and Tang, Shenglong and Shu, Zhaogang and Li, Di and Wang, Shiyong and Imran, Muhammad and Vasilakos, Athanasios V},
+ journal={IEEE Sensors Journal},
+ volume={16},
+ number={20},
+ pages={7373--7380},
+ year={2016},
+ publisher={IEEE}
+}
+
+@article{batory1992design,
+ title={The design and implementation of hierarchical software systems with reusable components},
+ author={Batory, Don and O'malley, Sean},
+ journal={ACM Transactions on Software Engineering and Methodology (TOSEM)},
+ volume={1},
+ number={4},
+ pages={355--398},
+ year={1992},
+ publisher={ACM New York, NY, USA}
+}
+
+@article{mockus2002two,
+ title={Two case studies of open source software development: Apache and Mozilla},
+ author={Mockus, Audris and Fielding, Roy T and Herbsleb, James D},
+ journal={ACM Transactions on Software Engineering and Methodology (TOSEM)},
+ volume={11},
+ number={3},
+ pages={309--346},
+ year={2002},
+ publisher={ACM New York, NY, USA}
+}
+
+@inproceedings{le2015microservice,
+ title={Microservice-based architecture for the NRDC},
+ author={Le, Vinh D and Neff, Melanie M and Stewart, Royal V and Kelley, Richard and Fritzinger, Eric and Dascalu, Sergiu M and Harris, Frederick C},
+ booktitle={2015 IEEE 13th International Conference on Industrial Informatics (INDIN)},
+ pages={1659--1664},
+ year={2015},
+ organization={IEEE},
+ publisher={IEEE},
+ address={Cambridge, UK},
+}
+
+@inproceedings{kodali2016low,
+ title={Low cost ambient monitoring using ESP8266},
+ author={Kodali, Ravi Kishore and Mahesh, Kopulwar Shishir},
+ booktitle={2016 2nd International Conference on Contemporary Computing and Informatics (IC3I)},
+ pages={779--782},
+ year={2016},
+ organization={IEEE},
+ publisher={IEEE},
+ address={Greater Noida, India}
+}
+
+@article{beaven1993explaining,
+ title={Explaining type errors in polymorphic languages},
+ author={Beaven, Mike and Stansifer, Ryan},
+ journal={ACM Letters on Programming Languages and Systems (LOPLAS)},
+ volume={2},
+ number={1-4},
+ pages={17--30},
+ year={1993},
+ publisher={ACM New York, NY, USA}
+}
+
+@phdthesis{armstrong2003making,
+ title={Making reliable distributed systems in the presence of software errors},
+ author={Armstrong, Joe},
+ year={2003}
+}
+
+@article{madsen1990strong,
+ title={Strong typing of object-oriented languages revisited},
+ author={Madsen, Ole Lehrmann and Magnusson, Boris and M{\o}lier-Pedersen, Birger},
+ journal={ACM SIGPLAN Notices},
+ volume={25},
+ number={10},
+ pages={140--150},
+ year={1990},
+ publisher={ACM New York, NY, USA}
+}
+
+@article{cass20182017,
+ title={The 2017 top programming languages},
+ author={Cass, Stephen},
+ journal={IEEE Spectrum},
+ volume={31},
+ year={2018}
+}
+
+@book{tollervey2017programming,
+ title={Programming with MicroPython: Embedded Programming with Microcontrollers and Python},
+ author={Tollervey, Nicholas H},
+ year={2017},
+ publisher={" O'Reilly Media, Inc."}
+}
+
+@inproceedings{alpernaswonderful,
+author = {Alpernas, Kalev and Feldman, Yotam M. Y. and Peleg, Hila},
+title = {The Wonderful Wizard of LoC: Paying Attention to the Man behind the Curtain of Lines-of-Code Metrics},
+year = {2020},
+isbn = {9781450381789},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/3426428.3426921},
+doi = {10.1145/3426428.3426921},
+abstract = {Lines-of-code metrics (loc) are commonly reported in Programming Languages (PL), Software Engineering (SE), and Systems papers. This convention has several different, often contradictory, goals, including demonstrating the `hardness' of a problem, and demonstrating the `easiness' of a problem. In many cases, the reporting of loc metrics is done not with a clearly communicated intention, but instead in an automatic, checkbox-ticking, manner. In this paper we investigate the uses of code metrics in PL, SE, and System papers. We consider the different goals that reporting metrics aims to achieve, several various domains wherein metrics are relevant, and various alternative metrics and their pros and cons for the different goals and domains. We argue that communicating claims about research software is usually best achieved not by reporting quantitative metrics, but by reporting the qualitative experience of researchers, and propose guidelines for the cases when quantitative metrics are appropriate. We end with a case study of the one area in which lines of code are not the default measurement---code produced by papers' solutions---and identify how measurements offered are used to support an explicit claim about the algorithm. Inspired by this positive example, we call for other cogent measures to be developed to support other claims authors wish to make.},
+booktitle = {Proceedings of the 2020 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Software},
+pages = {146–156},
+numpages = {11},
+keywords = {research papers, loc, lines of code},
+location = {Virtual, USA},
+series = {Onward! 2020}
+}
+
+@inproceedings{epstein2011towards,
+ author = {Epstein, Jeff and Black, Andrew P. and Peyton-Jones, Simon},
+ title = {Towards Haskell in the Cloud},
+ year = {2011},
+ isbn = {9781450308601},
+ publisher = {Association for Computing Machinery},
+ address = {New York, NY, USA},
+ url = {https://doi.org/10.1145/2034675.2034690},
+ doi = {10.1145/2034675.2034690},
+ abstract = {We present Cloud Haskell, a domain-specific language for developing programs for a distributed computing environment. Implemented as a shallow embedding in Haskell, it provides a message-passing communication model, inspired by Erlang, without introducing incompatibility with Haskell's established shared-memory concurrency. A key contribution is a method for serializing function closures for transmission across the network. Cloud Haskell has been implemented; we present example code and some preliminary performance measurements.},
+ booktitle = {Proceedings of the 4th ACM Symposium on Haskell},
+ pages = {118–129},
+ numpages = {12},
+ keywords = {message-passing, haskell, erlang},
+ location = {Tokyo, Japan},
+ series = {Haskell '11}
+}
+
+@book{gupta2012akka,
+ title={Akka essentials},
+ address={Livery Place, 35 Livery Street, Birmingham B3 2PB, UK},
+ author={Gupta, Munish},
+ year={2012},
+ publisher={Packt Publishing Ltd}
+}
+
+@article{millman2011python,
+ title={Python for scientists and engineers},
+ author={Millman, K Jarrod and Aivazis, Michael},
+ journal={Computing in Science \& Engineering},
+ volume={13},
+ number={2},
+ pages={9--12},
+ year={2011},
+ publisher={IEEE}
+}
+
+@misc{pyforum,
+ title = "Python Official Forum",
+ author = "",
+ year = "2021",
+ note = "https://www.python.org/community/forums/"
+}
+
+@misc{microforum,
+ title = "Micropython Official Forum",
+ author = "",
+ year = "2021",
+ note = "https://forum.micropython.org/"
+}
+
+@misc{microdocs,
+ title = "Official Micropython Docs",
+ author = "",
+ year = "2021",
+ note = "https://docs.micropython.org/en/latest/"
+}
+
+@misc{ wiki:IO,
+ author = "HaskellWiki",
+ title = "Introduction to IO --- HaskellWiki{,} ",
+ year = "2020",
+ url = "https://wiki.haskell.org/index.php?title=Introduction_to_IO&oldid=63493",
+ note = "[Online; accessed 19-January-2021]"
+}
+
+@misc{CircuitPython,
+ author = "CircuitPython Team",
+ title = "CircuitPython",
+ year = "2022",
+ url = "https://circuitpython.org/",
+ note = "[Online; accessed 2-March-2022]"
+}
+
+@article{barendsen_smetsers_1996,
+ title={Uniqueness typing for functional languages with graph rewriting semantics},
+ volume={6},
+ DOI={10.1017/S0960129500070109},
+ number={6},
+ journal={Mathematical Structures in Computer Science},
+ publisher={Cambridge University Press},
+ author={Barendsen, Erik and Smetsers, Sjaak},
+ year={1996},
+ pages={579–612}
+}
+@InProceedings{GenericProgrammingExtensionForClean,
+ author = "Alimarine, Artem and Plasmeijer, Rinus",
+ editor = "Arts, Thomas and Mohnen, Markus",
+ title="A Generic Programming Extension for Clean",
+ booktitle="Implementation of Functional Languages",
+ year="2002",
+ publisher="Springer Berlin Heidelberg",
+ address="Berlin, Heidelberg",
+ pages="168--185",
+ abstract="Generic programming enables the programmer to define functions by induction on the structure of types. Defined once, such a generic function can be used to generate a specialized function for any user defined data type. Several ways to support generic programming in functional languages have been proposed, each with its own pros and cons. In this paper we describe a combination of two existing approaches, which has the advantages of both of them. In our approach overloaded functions with class variables of an arbitrary kind can be defined generically. A single generic definition defines a kind-indexed family of overloaded functions, one for each kind. For instance, the generic mapping function generates an overloaded mapping function for each kind.",
+ isbn="978-3-540-46028-2"
+}
+@inproceedings{HinzeGenericFunctionalProgramming,
+ author = {Hinze, Ralf},
+ title = {A New Approach to Generic Functional Programming},
+ year = {2000},
+ isbn = {1581131259},
+ publisher = {Association for Computing Machinery},
+ address = {New York, NY, USA},
+ url = {https://doi.org/10.1145/325694.325709},
+ doi = {10.1145/325694.325709},
+ abstract = {This paper describes a new approach to generic functional programming, which allows us to define functions generically for all datatypes expressible in Haskell. A generic function is one that is defined by induction on the structure of types. Typical examples include pretty printers, parsers, and comparison functions. The advanced type system of Haskell presents a real challenge: datatypes may be parameterized not only by types but also by type constructors, type definitions may involve mutual recursion, and recursive calls of type constructors can be arbitrarily nested. We show that—despite this complexity—a generic function is uniquely defined by giving cases for primitive types and type constructors (such as disjoint unions and cartesian products). Given this information a generic function can be specialized to arbitrary Haskell datatypes. The key idea of the approach is to model types by terms of the simply typed λ-calculus augmented by a family of recursion operators. While conceptually simple, our approach places high demands on the type system: it requires polymorphic recursion, rank-n types, and a strong form of type constructor polymorphism. Finally, we point out connections to Haskell's class system and show that our approach generalizes type classes in some respects.},
+ booktitle = {Proceedings of the 27th ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages},
+ pages = {119–132},
+ numpages = {14},
+ location = {Boston, MA, USA},
+ series = {POPL '00}
+}
+@inproceedings{TOP-PPDP12,
+ author = {Plasmeijer, Rinus and Lijnse, Bas and Michels, Steffen and Achten, Peter and Koopman, Pieter},
+ title = {Task-Oriented Programming in a Pure Functional Language},
+ year = {2012},
+ isbn = {9781450315227},
+ publisher = {Association for Computing Machinery},
+ address = {New York, NY, USA},
+ 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},
+ pages = {195–206},
+ numpages = {12},
+ keywords = {task-oriented programming, clean},
+ location = {Leuven, Belgium},
+ series = {PPDP '12}
+}
+@inproceedings{
+ TOP-ICFP07,
+ author = {Plasmeijer, Rinus and Achten, Peter and Koopman, Pieter},
+ title = {{iTasks}: {E}xecutable {S}pecifications of {I}nteractive {W}ork {F}low {S}ystems for the {W}eb},
+ booktitle = {{P}roceedings of the 12th {ACM SIGPLAN} {I}nternational {C}onference on {F}unctional {P}rogramming ({ICFP} 2007)},
+ address = {{F}reiburg, {G}ermany},
+ year = 2007,
+ month = {Oct 1--3},
+ publisher = {ACM},
+ isbn = "978-1-59593-815-2",
+ pages = {141-152}
+}
+@article{FinallyTagless,
+ author = {Jacques Carette and Oleg Kiselyov and Chung{-}chieh Shan},
+ title = {Finally tagless, partially evaluated: Tagless staged interpreters
+ for simpler typed languages},
+ journal = {J. Funct. Program.},
+ volume = {19},
+ number = {5},
+ pages = {509--543},
+ year = {2009},
+ url = {https://doi.org/10.1017/S0956796809007205},
+ doi = {10.1017/S0956796809007205},
+ timestamp = {Sun, 02 Jun 2019 21:00:12 +0200},
+ biburl = {https://dblp.org/rec/journals/jfp/CaretteKS09.bib},
+ bibsource = {dblp computer science bibliography, https://dblp.org}
+}
+
+@inproceedings{oortgiese_distributed_2017,
+ title = {A {Distributed} {Dynamic} {Architecture} for {Task} {Oriented} {Programming}},
+ booktitle = {Proceedings of the 29th {Symposium} on {Implementation} and {Application} of {Functional} {Programming} {Languages}},
+ publisher = {ACM},
+ author = {Oortgiese, Arjan and van Groningen, John and Achten, Peter and Plasmeijer, Rinus},
+ year = {2017},
+ pages = {7},
+ address = {Bristol, UK}
+}
+
+@inproceedings{stefik14programming,
+ author = {Stefik, Andreas and Hanenberg, Stefan},
+ title = {The Programming Language Wars: Questions and Responsibilities for the Programming Language Community},
+ year = {2014},
+ doi = {10.1145/2661136.2661156},
+ booktitle = {Proceedings of the 2014 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming \& Software},
+ pages = {283--299},
+}
+
+@inproceedings{ParametricLenses,
+ author = {Domoszlai, L\'{a}szl\'{o} and Lijnse, Bas and Plasmeijer, Rinus},
+ title = {Parametric Lenses: Change Notification for Bidirectional Lenses},
+ year = {2014},
+ isbn = {9781450332842},
+ publisher = {Association for Computing Machinery},
+ address = {New York, NY, USA},
+ url = {https://doi.org/10.1145/2746325.2746333},
+ doi = {10.1145/2746325.2746333},
+ abstract = {Most complex applications inevitably need to maintain dependencies between subsystems based on some shared data. The dependent parts must be informed that the shared information is changed. As every actual notification has some communication cost, and every triggered task has associated computation cost, it is crucial for the overall performance of the application to reduce the number of notifications as much as possible. To achieve this, one must be able to define, with arbitrary precision, which party is depending on which data. In this paper we offer a general solution to this general problem. The solution is based on an extension to bidirectional lenses, called parametric lenses. With the help of parametric lenses one can define compositional parametric views in a declarative way to access some shared data. Parametric views, besides providing read/write access to the shared data, also enable to observe changes of some parts, given by an explicit parameter, the focus domain. The focus domain can be specified as a type-based query language defined over one or more resources using predefined combinators of parametric views.},
+ booktitle = {Proceedings of the 26th International Symposium on Implementation and Application of Functional Languages},
+ articleno = {9},
+ numpages = {11},
+ keywords = {notification systems, parametric views, lenses, parametric lenses, Bi-directional programming},
+ location = {Boston, MA, USA},
+ series = {IFL '14}
+}
+
+@inproceedings{steenvoorden_tophat_2019,
+ address = {New York, NY, USA},
+ 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}},
+ publisher = {Association for Computing Machinery},
+ author = {Steenvoorden, Tim and Naus, Nico and Klinik, Markus},
+ year = {2019},
+ note = {event-place: Porto, Portugal},
+ file = {Steenvoorden et al. - 2019 - TopHat A Formal Foundation for Task-Oriented Prog.pdf:/home/mrl/.local/share/zotero/storage/W7HJ5MEF/Steenvoorden et al. - 2019 - TopHat A Formal Foundation for Task-Oriented Prog.pdf:application/pdf}
+}
+
+@article{10.1145/1543134.1411301,
+ author = {Rodriguez, Alexey and Jeuring, Johan and Jansson, Patrik and Gerdes, Alex and Kiselyov, Oleg and Oliveira, Bruno C. d. S.},
+ title = {Comparing Libraries for Generic Programming in Haskell},
+ year = {2008},
+ issue_date = {February 2009},
+ publisher = {Association for Computing Machinery},
+ address = {New York, NY, USA},
+ volume = {44},
+ number = {2},
+ issn = {0362-1340},
+ url = {https://doi.org/10.1145/1543134.1411301},
+ doi = {10.1145/1543134.1411301},
+ abstract = {Datatype-generic programming is defining functions that depend on the structure, or "shape", of datatypes. It has been around for more than 10 years, and a lot of progress has been made, in particular in the lazy functional programming language Haskell. There are morethan 10 proposals for generic programming libraries orlanguage extensions for Haskell. To compare and characterise the many generic programming libraries in atyped functional language, we introduce a set of criteria and develop a generic programming benchmark: a set of characteristic examples testing various facets of datatype-generic programming. We have implemented the benchmark for nine existing Haskell generic programming libraries and present the evaluation of the libraries. The comparison is useful for reaching a common standard for generic programming, but also for a programmer who has to choose a particular approach for datatype-generic programming.},
+ journal = {SIGPLAN Not.},
+ month = sep,
+ pages = {111–122},
+ numpages = {12},
+ keywords = {datatype-generic programming, libraries comparison}
+}
+
+@inproceedings{ComparingGenericProgramming,
+ author = {Rodriguez, Alexey and Jeuring, Johan and Jansson, Patrik and Gerdes, Alex and Kiselyov, Oleg and Oliveira, Bruno C. d. S.},
+ title = {Comparing Libraries for Generic Programming in Haskell},
+ year = {2008},
+ isbn = {9781605580647},
+ publisher = {Association for Computing Machinery},
+ address = {New York, NY, USA},
+ url = {https://doi.org/10.1145/1411286.1411301},
+ doi = {10.1145/1411286.1411301},
+ abstract = {Datatype-generic programming is defining functions that depend on the structure, or "shape", of datatypes. It has been around for more than 10 years, and a lot of progress has been made, in particular in the lazy functional programming language Haskell. There are morethan 10 proposals for generic programming libraries orlanguage extensions for Haskell. To compare and characterise the many generic programming libraries in atyped functional language, we introduce a set of criteria and develop a generic programming benchmark: a set of characteristic examples testing various facets of datatype-generic programming. We have implemented the benchmark for nine existing Haskell generic programming libraries and present the evaluation of the libraries. The comparison is useful for reaching a common standard for generic programming, but also for a programmer who has to choose a particular approach for datatype-generic programming.},
+ booktitle = {Proceedings of the First ACM SIGPLAN Symposium on Haskell},
+ pages = {111–122},
+ numpages = {12},
+ keywords = {datatype-generic programming, libraries comparison},
+ location = {Victoria, BC, Canada},
+ series = {Haskell '08}
+}
+
+@InProceedings{ComposingReactiveGUIs,
+ author="Bjornson, Joel
+ and Tayanovskyy, Anton
+ and Granicz, Adam",
+ editor="Hage, Jurriaan
+ and Moraz{\'a}n, Marco T.",
+ title="Composing Reactive GUIs in F{\#} Using WebSharper",
+ booktitle="Implementation and Application of Functional Languages",
+ year="2011",
+ publisher="Springer Berlin Heidelberg",
+ address="Berlin, Heidelberg",
+ pages="203--216",
+ abstract="We present a generic library for constructing composable and interactive user interfaces in a declarative style. The paper introduces flowlets, an extension of formlets[3,2] providing interactivity. Real-world examples are given using the current implementation that compiles flowlets defined in F{\#} to JavaScript with WebSharper.",
+ isbn="978-3-642-24276-2"
+}
+
+@inproceedings{FunctionalReactiveAnimation,
+ author = {Elliott, Conal and Hudak, Paul},
+ title = {Functional Reactive Animation},
+ year = {1997},
+ isbn = {0897919181},
+ publisher = {Association for Computing Machinery},
+ address = {New York, NY, USA},
+ url = {https://doi.org/10.1145/258948.258973},
+ doi = {10.1145/258948.258973},
+ abstract = {Fran (Functional Reactive Animation) is a collection of data types and functions for composing richly interactive, multimedia animations. The key ideas in Fran are its notions of behaviors and events. Behaviors are time-varying, reactive values, while events are sets of arbitrarily complex conditions, carrying possibly rich information. Most traditional values can be treated as behaviors, and when images are thus treated, they become animations. Although these notions are captured as data types rather than a programming language, we provide them with a denotational semantics, including a proper treatment of real time, to guide reasoning and implementation. A method to effectively and efficiently perform event detection using interval analysis is also described, which relies on the partial information structure on the domain of event times. Fran has been implemented in Hugs, yielding surprisingly good performance for an interpreter-based system. Several examples are given, including the ability to describe physical phenomena involving gravity, springs, velocity, acceleration, etc. using ordinary differential equations.},
+ booktitle = {Proceedings of the Second ACM SIGPLAN International Conference on Functional Programming},
+ pages = {263–273},
+ numpages = {11},
+ location = {Amsterdam, The Netherlands},
+ series = {ICFP '97}
+}
+
+@inproceedings{kochhar2016large,
+ author={P. S. {Kochhar} and D. {Wijedasa} and D. {Lo}},
+ booktitle={23rd International Conference on Software Analysis, Evolution, and Reengineering},
+ title={A Large Scale Study of Multiple Programming Languages and Code Quality},
+ year={2016},
+ pages={563--573},
+ doi={10.1109/SANER.2016.112},
+ address={Osaka, Japan},
+ publisher={IEEE}
+}
+
+@inproceedings{hao2020approaching,
+ author = {Rebecca L. Hao and Elena L. Glassman},
+ title = {{Approaching Polyglot Programming: What Can We Learn from Bilingualism Studies?}},
+ booktitle = {10th Workshop on Evaluation and Usability of Programming Languages and Tools (PLATEAU 2019)},
+ pages = {1:1--1:7},
+ year = {2020},
+ volume = {76},
+ doi = {10.4230/OASIcs.PLATEAU.2019.1},
+}
+
+@article{cass2020top,
+ title={The top programming languages: Our latest rankings put Python on top-again-[Careers]},
+ author={Cass, Stephen},
+ journal={IEEE Spectrum},
+ volume={57},
+ number={8},
+ pages={22--22},
+ year={2020},
+ publisher={IEEE}
+}
+
+@inproceedings{tanganelli2015coapthon,
+ title={CoAPthon: Easy development of CoAP-based IoT applications with Python},
+ author={Tanganelli, Giacomo and Vallati, Carlo and Mingozzi, Enzo},
+ booktitle={2015 IEEE 2nd World Forum on Internet of Things (WF-IoT)},
+ pages={63--68},
+ year={2015},
+ publisher={IEEE},
+ address={Milan, Italy}
+}
+
+@INPROCEEDINGS{Wadler92comprehendingmonads,
+author = {Wadler, Philip},
+title = {Comprehending Monads},
+year = {1990},
+isbn = {089791368X},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/91556.91592},
+doi = {10.1145/91556.91592},
+abstract = {Category theorists invented monads in the 1960's to concisely express certain aspects of universal algebra. Functional programmers invented list comprehensions in the 1970's to concisely express certain programs involving lists. This paper shows how list comprehensions may be generalised to an arbitrary monad, and how the resulting programming feature can concisely express in a pure functional language some programs that manipulate state, handle exceptions, parse text, or invoke continuations. A new solution to the old problem of destructive array update is also presented. No knowledge of category theory is assumed.},
+booktitle = {Proceedings of the 1990 ACM Conference on LISP and Functional Programming},
+pages = {61–78},
+numpages = {18},
+location = {Nice, France},
+series = {LFP '90}
+}
+@misc{smartcampus,
+ author = {Mott Macdonald},
+ title = "University of Glasgow Smart Campus Digital Masterplan",
+ year = "2019",
+ note = "\url{https://www.gla.ac.uk/media/Media_702108_smxx.pdf}",
+}
+
+@misc{IIO,
+ author = "Bijan Mottahedeh",
+ title = "An Introduction to the io XXX uring Asynchronous I/O Framework",
+ year = "2020",
+ url = "https://blogs.oracle.com/linux/an-introduction-to-the-io XXX uring-asynchronous-io-framework",
+ note = "[Online; accessed 13-May-2021]"
+}
+
+@inproceedings{10.1145/1806596.1806601,
+author = {Lee, Byeongcheol and Wiedermann, Ben and Hirzel, Martin and Grimm, Robert and McKinley, Kathryn S.},
+title = {Jinn: Synthesizing Dynamic Bug Detectors for Foreign Language Interfaces},
+year = {2010},
+isbn = {9781450300193},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/1806596.1806601},
+doi = {10.1145/1806596.1806601},
+abstract = {Programming language specifications mandate static and dynamic analyses to preclude syntactic and semantic errors. Although individual languages are usually well-specified, composing languages is not, and this poor specification is a source of many errors in multilingual programs. For example, virtually all Java programs compose Java and C using the Java Native Interface (JNI). Since JNI is informally specified, developers have difficulty using it correctly, and current Java compilers and virtual machines (VMs) inconsistently check only a subset of JNI constraints.This paper's most significant contribution is to show how to synthesize dynamic analyses from state machines to detect foreign function interface (FFI) violations. We identify three classes of FFI constraints encoded by eleven state machines that capture thousands of JNI and Python/C FFI rules. We use a mapping function to specify which state machines, transitions, and program entities (threads, objects, references) to check at each FFI call and return. From this function, we synthesize a context-specific dynamic analysis to find FFI bugs. We build bug detection tools for JNI and Python/C using this approach. For JNI, we dynamically and transparently interpose the analysis on Java and C language transitions through the JVM tools interface. The resulting tool, called Jinn, is compiler and virtual machine independent. It detects and diagnoses a wide variety of FFI bugs that other tools miss. This approach greatly reduces the annotation burden by exploiting common FFI constraints: whereas the generated Jinn code is 22,000+ lines, we wrote only 1,400 lines of state machine and mapping code. Overall, this paper lays the foundation for a more principled approach to developing correct multilingual software and a more concise and automated approach to FFI specification.},
+booktitle = {Proceedings of the 31st ACM SIGPLAN Conference on Programming Language Design and Implementation},
+pages = {36–49},
+numpages = {14},
+keywords = {dynamic analysis, multilingual programs, foreign function interfaces (FFI), python/C, java native interface (jni), specification, specification generation, ffi bugs},
+location = {Toronto, Ontario, Canada},
+series = {PLDI '10}
+}
+
+
+@article{Jinn
+,
+author = {Lee, Byeongcheol and Wiedermann, Ben and Hirzel, Martin and Grimm, Robert and McKinley, Kathryn S.},
+title = {Jinn: Synthesizing Dynamic Bug Detectors for Foreign Language Interfaces},
+year = {2010},
+issue_date = {June 2010},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+volume = {45},
+number = {6},
+issn = {0362-1340},
+url = {https://doi.org/10.1145/1809028.1806601},
+doi = {10.1145/1809028.1806601},
+abstract = {Programming language specifications mandate static and dynamic analyses to preclude syntactic and semantic errors. Although individual languages are usually well-specified, composing languages is not, and this poor specification is a source of many errors in multilingual programs. For example, virtually all Java programs compose Java and C using the Java Native Interface (JNI). Since JNI is informally specified, developers have difficulty using it correctly, and current Java compilers and virtual machines (VMs) inconsistently check only a subset of JNI constraints.This paper's most significant contribution is to show how to synthesize dynamic analyses from state machines to detect foreign function interface (FFI) violations. We identify three classes of FFI constraints encoded by eleven state machines that capture thousands of JNI and Python/C FFI rules. We use a mapping function to specify which state machines, transitions, and program entities (threads, objects, references) to check at each FFI call and return. From this function, we synthesize a context-specific dynamic analysis to find FFI bugs. We build bug detection tools for JNI and Python/C using this approach. For JNI, we dynamically and transparently interpose the analysis on Java and C language transitions through the JVM tools interface. The resulting tool, called Jinn, is compiler and virtual machine independent. It detects and diagnoses a wide variety of FFI bugs that other tools miss. This approach greatly reduces the annotation burden by exploiting common FFI constraints: whereas the generated Jinn code is 22,000+ lines, we wrote only 1,400 lines of state machine and mapping code. Overall, this paper lays the foundation for a more principled approach to developing correct multilingual software and a more concise and automated approach to FFI specification.},
+journal = {SIGPLAN Not.},
+month = jun,
+pages = {36–49},
+numpages = {14},
+keywords = {specification generation, specification, python/C, dynamic analysis, multilingual programs, java native interface (jni), foreign function interfaces (FFI), ffi bugs}
+}
+@inproceedings{10.1145/1065010.1065019,
+author = {Furr, Michael and Foster, Jeffrey S.},
+title = {Checking Type Safety of Foreign Function Calls},
+year = {2005},
+isbn = {1595930566},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/1065010.1065019},
+doi = {10.1145/1065010.1065019},
+abstract = {We present a multi-lingual type inference system for checking type safety across a foreign function interface. The goal of our system is to prevent foreign function calls from introducing type and memory safety violations into an otherwise safe language. Our system targets OCaml's FFI to C, which is relatively lightweight and illustrates some interesting challenges in multi-lingual type inference. The type language in our system embeds OCaml types in C types and vice-versa, which allows us to track type information accurately even through the foreign language, where the original types are lost. Our system uses representational types that can model multiple OCaml types, because C programs can observe that many OCaml types have the same physical representation. Furthermore, because C has a low-level view of OCaml data, our inference system includes a dataflow analysis to track memory offsets and tag information. Finally, our type system includes garbage collection information to ensure that pointers from the FFI to the OCaml heap are tracked properly. We have implemented our inference system and applied it to a small set of benchmarks. Our results show that programmers do misuse these interfaces, and our implementation has found several bugs and questionable coding practices in our benchmarks.},
+booktitle = {Proceedings of the 2005 ACM SIGPLAN Conference on Programming Language Design and Implementation},
+pages = {62–72},
+numpages = {11},
+keywords = {dataflow analysis, multi-lingual type system, representational type, flow-sensitive type system, foreign function interface, FFI, multi-lingual type inference, foreign function calls, OCaml},
+location = {Chicago, IL, USA},
+series = {PLDI '05}
+}
+
+@article{Furr2005,
+author = {Furr, Michael and Foster, Jeffrey S.},
+title = {Checking Type Safety of Foreign Function Calls},
+year = {2005},
+issue_date = {June 2005},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+volume = {40},
+number = {6},
+issn = {0362-1340},
+url = {https://doi.org/10.1145/1064978.1065019},
+doi = {10.1145/1064978.1065019},
+abstract = {We present a multi-lingual type inference system for checking type safety across a foreign function interface. The goal of our system is to prevent foreign function calls from introducing type and memory safety violations into an otherwise safe language. Our system targets OCaml's FFI to C, which is relatively lightweight and illustrates some interesting challenges in multi-lingual type inference. The type language in our system embeds OCaml types in C types and vice-versa, which allows us to track type information accurately even through the foreign language, where the original types are lost. Our system uses representational types that can model multiple OCaml types, because C programs can observe that many OCaml types have the same physical representation. Furthermore, because C has a low-level view of OCaml data, our inference system includes a dataflow analysis to track memory offsets and tag information. Finally, our type system includes garbage collection information to ensure that pointers from the FFI to the OCaml heap are tracked properly. We have implemented our inference system and applied it to a small set of benchmarks. Our results show that programmers do misuse these interfaces, and our implementation has found several bugs and questionable coding practices in our benchmarks.},
+journal = {SIGPLAN Not.},
+month = jun,
+pages = {62–72},
+numpages = {11},
+keywords = {foreign function calls, multi-lingual type system, OCaml, multi-lingual type inference, flow-sensitive type system, FFI, foreign function interface, dataflow analysis, representational type}
+}
+
+@INPROCEEDINGS{LubbersMIPRO,
+ author={Lubbers, Mart and Koopman, Pieter and Plasmeijer, Rinus},
+ booktitle={2019 42nd International Convention on Information and Communication Technology, Electronics and Microelectronics (MIPRO)},
+ title={Multitasking on Microcontrollers using Task Oriented Programming},
+ year={2019},
+ volume={},
+ number={},
+ pages={1587-1592},
+ publisher={IEEE},
+ address={Opatija, Croatia},
+ doi={10.23919/MIPRO.2019.8756711}}
+
+@inproceedings{plamauer2017evaluation,
+ title={Evaluation of micropython as application layer programming language on cubesats},
+ author={Plamauer, Sebastian and Langer, Martin},
+ booktitle={ARCS 2017; 30th International Conference on Architecture of Computing Systems},
+ pages={1--9},
+ year={2017},
+ organization={VDE},
+ publisher={VDE},
+ address={Vienna, Austria}
+}
+
+@inproceedings{egyed1999automatically,
+ title={Automatically detecting mismatches during component-based and model-based development},
+ author={Egyed, Alexander and Gacek, Cristina},
+ booktitle={14th IEEE International Conference on Automated Software Engineering},
+ pages={191--198},
+ year={1999},
+ organization={IEEE}
+}
+
+@inproceedings{suchocki_microscheme:_2015,
+ title = {Microscheme: {Functional} programming for the {Arduino}},
+ booktitle = {Proceedings of the 2014 {Scheme} and {Functional} {Programming} {Workshop}},
+ author = {Suchocki, Ryan and Kalvala, Sara},
+ publisher = {University of Indiana},
+ address = {Washington DC, USA},
+ year = {2015},
+ pages = {9},
+}
+
+@misc{johnson-davies_lisp_2020,
+ title = {Lisp for microcontrollers},
+ url = {https://ulisp.com},
+ urldate = {2020-02-14},
+ journal = {Lisp for microcontrollers},
+ author = {Johnson-Davies, David},
+ year = {2020},
+ address = {Boston, MA, USA},
+}
+
+@article{dube_bit:_2000,
+ title = {{BIT}: {A} very compact {Scheme} system for embedded applications},
+ journal = {Proceedings of the Fourth Workshop on Scheme and Functional Programming},
+ author = {Dubé, Danny},
+ year = {2000},
+ file = {dube.ps:/home/mrl/.local/share/zotero/storage/RNG6V7HT/dube.ps:application/postscript},
+}
+
+@inproceedings{feeley_picbit:_2003,
+ title = {{PICBIT}: {A} {Scheme} system for the {PIC} microcontroller},
+ booktitle = {Proceedings of the {Fourth} {Workshop} on {Scheme} and {Functional} {Programming}},
+ publisher = {Citeseer},
+ author = {Feeley, Marc and Dubé, Danny},
+ year = {2003},
+ pages = {7--15},
+ address = {Boston, MA, USA},
+}
+
+@inproceedings{st-amour_picobit:_2009,
+ title = {{PICOBIT}: a compact scheme system for microcontrollers},
+ booktitle = {International {Symposium} on {Implementation} and {Application} of {Functional} {Languages}},
+ publisher = {Springer},
+ author = {St-Amour, Vincent and Feeley, Marc},
+ year = {2009},
+ pages = {1--17},
+ address = {South Orange, NJ, USA},
+}
+@book{Ravulavaru18,
+author = {Ravulavaru, Arvind},
+isbn = {1-78883-378-3},
+language = {eng},
+publisher = {Packt Publishing},
+title = {Enterprise internet of things handbook : build end-to-end IoT solutions using popular IoT platforms},
+year = {2018},
+address = {Birmingham, UK},
+}
+
+@InProceedings{Alphonsa20,
+author="Alphonsa, Mandla",
+editor="Kumar, Amit
+and Mozar, Stefan",
+title="A Review on IOT Technology Stack, Architecture and Its Cloud Applications in Recent Trends",
+booktitle="ICCCE 2020",
+year="2021",
+publisher="Springer Singapore",
+address="Singapore",
+pages="703--711",
+abstract="The Internet of Things (IoT) senses, gather and transmit data over the internet without any human interference. This technology is a mixture of embedded technology, network technology and information technology. On various advancement of huge network and the broadcasting of (IoT), wireless sensored networks are considered to be part of the huge heterogeneous network. IoT architecture is the system of various rudiments like sensored networks, protocol, actuators, cloud service and layers. Internet of Things can also be called as an event-driven model. The IOT device is connected to gateway through Radio Frequency, LORA-WAN, Node MCU Pin-out. This review paper describes all protocol stack including its types of sensors in IOT their applications in real time environment and its architecture. In this paper we come together with the two different technologies Cloud Computing and IoT to observe the most common features, and to determine the benefits of their integration. The Cloud IoT prototype involves various applications, research issues and challenges.",
+isbn="978-981-15-7961-5"
+}
+@inproceedings{jones_clean_io,
+author = {Jones, Simon B},
+title = {Experiences with Clean I/O},
+year = {1995},
+publisher = {BCS Learning \& Development Ltd.},
+address = {Swindon, GBR},
+abstract = {The Clean system is a powerful functional programming tool. It contains experiments
+in a number of different areas of functional language design. In particular, it has
+a novel proposal for the organization of input and output, and contains impressive
+libraries of facilities for programming graphical user interfaces.Clean I/O is based
+on collections of operations that act to cause side effects on multiple explicit abstract
+values representing physical I/O entities, such as files and graphical interfaces.
+A system of unique types is used to ensure that these values are individually single
+threaded through the program; and the side effecting I/O operations are therefore
+well controlled. This approach is distinct from monadic I/O, which is being widely
+adopted; monadic I/O schemes are based on a single, implicit environment, and guarantee
+that this is single threaded.In this paper we will show that the Clean and monadic
+approaches to I/O merge nicely. The functionality provided by the Clean and its I/O
+libraries allows libraries for monadic I/O to be implemented. The paper presents an
+implementation of a basic I/O monad library in Clean that can serve for future development.
+In itself, the fact that the monadic approach can be implemented in Clean is unsurprising.
+However, some interesting technical difficulties arose during implementation of the
+monad; these and their solutions are discussed. The opportunity to express programs
+using the implicit environments of monadic I/O allows us to simplify Clean programs
+by removing some of the spaghetti, whilst retaining the generality of the explicit
+environments where it is the most appropriate approach.},
+booktitle = {Proceedings of the 1995 International Conference on Functional Programming},
+pages = {167–177},
+numpages = {11},
+location = {Glasgow, UK},
+series = {FP'95}
+}
+
+@inproceedings{sivieri2012drop,
+ title={Drop the phone and talk to the physical world: Programming the internet of things with Erlang},
+ author={Sivieri, Alessandro and Mottola, Luca and Cugola, Gianpaolo},
+ booktitle={2012 Third International Workshop on Software Engineering for Sensor Network Applications (SESENA)},
+ pages={8--14},
+ year={2012},
+ organization={IEEE}
+}
+
+@article{chong2007secure,
+ title={Secure web applications via automatic partitioning},
+ author={Chong, Stephen and Liu, Jed and Myers, Andrew C and Qi, Xin and Vikram, Krishnaprasad and Zheng, Lantian and Zheng, Xin},
+ journal={ACM SIGOPS Operating Systems Review},
+ volume={41},
+ number={6},
+ pages={31--44},
+ year={2007},
+ publisher={ACM New York, NY, USA}
+}
+
+@article{zdancewic2002secure,
+ title={Secure program partitioning},
+ author={Zdancewic, Steve and Zheng, Lantian and Nystrom, Nathaniel and Myers, Andrew C},
+ journal={ACM Transactions on Computer Systems (TOCS)},
+ volume={20},
+ number={3},
+ pages={283--328},
+ year={2002},
+ publisher={ACM New York, NY, USA}
+}
+
+@article{bhatt2012analysis,
+ title={Analysis of source lines of code (SLOC) metric},
+ author={Bhatt, Kaushal and Tarey, Vinit and Patel, Pushpraj and Mits, Kaushal Bhatt and Ujjain, Datana},
+ journal={International Journal of Emerging Technology and Advanced Engineering},
+ volume={2},
+ number={5},
+ pages={150--154},
+ year={2012},
+ publisher={Citeseer}
+}
+
+@article{10.1145/2775050.2633367,
+author = {Ekblad, Anton and Claessen, Koen},
+title = {A Seamless, Client-Centric Programming Model for Type Safe Web Applications},
+year = {2014},
+issue_date = {December 2014},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+volume = {49},
+number = {12},
+issn = {0362-1340},
+url = {https://doi.org/10.1145/2775050.2633367},
+doi = {10.1145/2775050.2633367},
+abstract = {We propose a new programming model for web applications which is (1) seamless; one program and one language is used to produce code for both client and server, (2) client-centric; the programmer takes the viewpoint of the client that runs code on the server rather than the other way around, (3) functional and type-safe, and (4) portable; everything is implemented as a Haskell library that implicitly takes care of all networking code. Our aim is to improve the painful and error-prone experience of today's standard development methods, in which clients and servers are coded in different languages and communicate with each other using ad-hoc protocols. We present the design of our library called Haste.App, an example web application that uses it, and discuss the implementation and the compiler technology on which it depends.},
+journal = {SIGPLAN Not.},
+month = {sep},
+pages = {79–89},
+numpages = {11},
+keywords = {distributed systems, web applications, network communication}
+}
+
+@article{jones_1992, title={Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine}, volume={2}, DOI={10.1017/S0956796800000319}, number={2}, journal={Journal of Functional Programming}, publisher={Cambridge University Press}, author={Jones, Simon L. Peyton}, year={1992}, pages={127–202}}
+
+
+@article{domoszlai_implementing_2011,
+ title = {Implementing a non-strict purely functional language in {JavaScript}},
+ volume = {3},
+ url = {https://www.researchgate.net/profile/Jan_Martin_Jansen2/publication/230607075_Implementing_a_non-strict_purely_functional_language_in_JavaScript/links/53fc40190cf22f21c2f3b28a.pdf},
+ urldate = {2017-05-23},
+ journal = {Acta Universitatis Sapientiae},
+ author = {Domoszlai, Laszlo and Bruel, Eddy and Jansen, Jan Martin},
+ year = {2011},
+ pages = {76--98},
+ file = {53fc40190cf22f21c2f3b28a.pdf:/home/mrl/.local/share/zotero/storage/2EVHREI3/53fc40190cf22f21c2f3b28a.pdf:application/pdf},
+}
+@Inbook{Domoszlai2013,
+author={Domoszlai, L{\'a}szl{\'o} and Kozsik, Tam{\'a}s},
+editor={Achten, Peter and Koopman, Pieter},
+title={Clean Up the Web!},
+bookTitle={The Beauty of Functional Code: Essays Dedicated to Rinus Plasmeijer on the Occasion of His 61st Birthday},
+year=2013,
+publisher={Springer Berlin Heidelberg},
+address={Berlin, Heidelberg},
+pages={133--150},
+abstract={Programming in Clean is much more appealing than programming in JavaScript. Therefore, solutions that can replace JavaScript with Clean in client-side web development are widely welcomed. This paper describes a technology for the cross-compilation of Clean to JavaScript and for the tight integration of the generated code into a web application. Our solution is based on the iTask framework and its extension, the so-called Tasklets. The application server approach provides simple and easy deployment, thus supporting rapid development. Examples are shown to illustrate how communication between the Clean and JavaScript code can be established.},
+isbn={978-3-642-40355-2},
+doi={10.1007/978-3-642-40355-2_10},
+url={https://doi.org/10.1007/978-3-642-40355-2_10}
+}
+
+@inproceedings{10.1145/3412932.3412941,
+author = {Staps, Camil and van Groningen, John and Plasmeijer, Rinus},
+title = {Lazy Interworking of Compiled and Interpreted Code for Sandboxing and Distributed Systems},
+year = {2019},
+isbn = {9781450375627},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/3412932.3412941},
+doi = {10.1145/3412932.3412941},
+abstract = {More and more applications rely on the safe execution of code unknown at compile-time, for example in the implementation of web browsers and plugin systems. Furthermore, these applications usually require some form of communication between the added code and its embedder, and hence a communication channel must be set up in which values are serialized and deserialized. This paper shows that in a functional programming language we can solve these two problems at once, if we realize that the execution of extra code is nothing more than the deserialization of a value which happens to be a function. To demonstrate this, we describe the implementation of a serialization library for the language Clean, which internally uses an interpreter to evaluate added code in a separate, sandboxed environment. Remarkable is that despite the conceptual asymmetry between "host" and "interpreter", lazy interworking must be implemented in a highly symmetric fashion, much akin to distributed systems. The library interworks on a low level with the native Clean program, but has been implemented without any changes to the native runtime system. It can therefore easily be ported to other programming languages.We can use the same technique in the context of the web, where we want to be able to share possibly lazy values between a server and a client. In this case the interpreter runs in WebAssembly in the browser and communicates seamlessly with the server, written in Clean. We use this in the iTasks web framework to handle communication and offload computations to the client to reduce stress on the server-side. Previously, this framework cross-compiled the Clean source code to JavaScript and used JSON for communication. The interpreter has a more predictable and better performance, and integration is much simpler because it interworks on a lower level with the web server.},
+booktitle = {Proceedings of the 31st Symposium on Implementation and Application of Functional Languages},
+articleno = {9},
+numpages = {12},
+keywords = {functional programming, sandboxing, web-assembly, laziness, interpreters},
+location = {Singapore, Singapore},
+series = {IFL '19}
+}
+
+@inproceedings{elliott_guilt_2015,
+ title = {Guilt free ivory},
+ volume = {50},
+ booktitle = {{ACM} {SIGPLAN} {Notices}},
+ publisher = {ACM},
+ author = {Elliott, Trevor and Pike, Lee and Winwood, Simon and Hickey, Pat and Bielman, James and Sharp, Jamey and Seidel, Eric and Launchbury, John},
+ year = {2015},
+ pages = {189--200},
+ file = {5678351608ae125516ee79c6.pdf:/home/mrl/.local/share/zotero/storage/KJMFUH7T/5678351608ae125516ee79c6.pdf:application/pdf},
+}
+
+@inproceedings{sawada_emfrp:_2016,
+ title = {Emfrp: a functional reactive programming language for small-scale embedded systems},
+ booktitle = {Companion {Proceedings} of the 15th {International} {Conference} on {Modularity}},
+ publisher = {ACM},
+ author = {Sawada, Kensuke and Watanabe, Takuo},
+ year = {2016},
+ pages = {36--44},
+ file = {Sawada and Watanabe - 2016 - Emfrp a functional reactive programming language .pdf:/home/mrl/.local/share/zotero/storage/9U95ER5P/Sawada and Watanabe - 2016 - Emfrp a functional reactive programming language .pdf:application/pdf},
+}
+
+@inproceedings{lv_designing_2018,
+ title = {Designing of {IoT} {Platform} {Based} on {Functional} {Reactive} {Pattern}},
+ booktitle = {2018 {International} {Conference} on {Computer} {Science}, {Electronics} and {Communication} {Engineering} ({CSECE} 2018)},
+ publisher = {Atlantis Press},
+ author = {Lv, Haidong and Ge, Xiaolong and Zhu, Hongzhi and Yuan, Zhiwei and Wang, Zhen and Zhu, Yongkang},
+ year = {2018},
+ file = {Lv et al. - 2018 - Designing of IoT Platform Based on Functional Reac.pdf:/home/mrl/.local/share/zotero/storage/IBVT6MHW/Lv et al. - 2018 - Designing of IoT Platform Based on Functional Reac.pdf:application/pdf},
+}
+
+@inproceedings{helbling_juniper:_2016,
+ title = {Juniper: a functional reactive programming language for the {Arduino}},
+ booktitle = {Proceedings of the 4th {International} {Workshop} on {Functional} {Art}, {Music}, {Modelling}, and {Design}},
+ publisher = {ACM},
+ author = {Helbling, Caleb and Guyer, Samuel Z},
+ year = {2016},
+ pages = {8--16},
+ file = {Helbling and Guyer - 2016 - Juniper a functional reactive programming languag.pdf:/home/mrl/.local/share/zotero/storage/M4UWK57F/Helbling and Guyer - 2016 - Juniper a functional reactive programming languag.pdf:application/pdf},
+}
+
+@incollection{wang_functional_2020,
+ address = {Cham},
+ title = {Functional {Reactive} {EDSL} with {Asynchronous} {Execution} for {Resource}-{Constrained} {Embedded} {Systems}},
+ isbn = {978-3-030-26428-4},
+ url = {https://doi.org/10.1007/978-3-030-26428-4_12},
+ abstract = {This paper presents a functionalWang, Sheng reactive embedded domain-specific language (EDSL) for resource-constrained embedded systems and its efficient execution method. In the language, time-varying values changes at discrete points of time rather than continuously. Combined with a mechanismWatanabe, Takuo to let users designate the update interval of values, it is possible to derive the minimal value-updates required to produce the user-desired output. Also, the event-driven backend asynchronously updates an input value when its value is required. In this way, we can greatly reduce the number of updates.},
+ booktitle = {Software {Engineering}, {Artificial} {Intelligence}, {Networking} and {Parallel}/{Distributed} {Computing}},
+ publisher = {Springer International Publishing},
+ author = {Wang, Sheng and Watanabe, Takuo},
+ editor = {Lee, Roger},
+ year = {2020},
+ doi = {10.1007/978-3-030-26428-4_12},
+ pages = {171--190},
+ file = {Wang and Watanabe - 2020 - Functional Reactive EDSL with Asynchronous Executi.pdf:/home/mrl/.local/share/zotero/storage/5JUBWXYV/Wang and Watanabe - 2020 - Functional Reactive EDSL with Asynchronous Executi.pdf:application/pdf},
+}
+
+@incollection{valliappan_towards_2020,
+ address = {New York, NY, USA},
+ title = {Towards {Secure} {IoT} {Programming} in {Haskell}},
+ isbn = {978-1-4503-8050-8},
+ url = {https://doi.org/10.1145/3406088.3409027},
+ abstract = {IoT applications are often developed in programming languages with low-level abstractions, where a seemingly innocent mistake might lead to severe security vulnerabilities. Current IoT development tools make it hard to identify these vulnerabilities as they do not provide end-to-end guarantees about how data flows within and between appliances. In this work we present Haski, an embedded domain specific language in Haskell (eDSL) for secure programming of IoT devices. Haski enables developers to write Haskell programs that generate C code without falling into many of C’s pitfalls. Haski is designed after the synchronous programming language Lustre, and sports a backwards compatible information-flow control extension to restrict how sensitive data is propagated and modified within the application. We present a novel eDSL design which uses recursive monadic bindings and allows a natural use of functions and pattern-matching in Haskell to write Haski programs. To showcase Haski, we implement a simple smart house controller where communication is done via low-energy Bluetooth on Zephyr OS.},
+ booktitle = {Proceedings of the 13th {ACM} {SIGPLAN} {International} {Symposium} on {Haskell}},
+ publisher = {Association for Computing Machinery},
+ author = {Valliappan, Nachiappan and Krook, Robert and Russo, Alejandro and Claessen, Koen},
+ year = {2020},
+ pages = {136--150},
+ file = {Valliappan et al. - 2020 - Towards Secure IoT Programming in Haskell.pdf:/home/mrl/.local/share/zotero/storage/BF6YIT2S/Valliappan et al. - 2020 - Towards Secure IoT Programming in Haskell.pdf:application/pdf},
+}
+
+@inproceedings{sarkar_hailstorm_2020,
+ address = {New York, NY, USA},
+ series = {{PPDP} '20},
+ title = {Hailstorm: {A} {Statically}-{Typed}, {Purely} {Functional} {Language} for {IoT} {Applications}},
+ isbn = {978-1-4503-8821-4},
+ url = {https://doi.org/10.1145/3414080.3414092},
+ doi = {10.1145/3414080.3414092},
+ abstract = {With the growing ubiquity of Internet of Things (IoT), more complex logic is being programmed on resource-constrained IoT devices, almost exclusively using the C programming language. While C provides low-level control over memory, it lacks a number of high-level programming abstractions such as higher-order functions, polymorphism, strong static typing, memory safety, and automatic memory management. We present Hailstorm, a statically-typed, purely functional programming language that attempts to address the above problem. It is a high-level programming language with a strict typing discipline. It supports features like higher-order functions, tail-recursion, and automatic memory management, to program IoT devices in a declarative manner. Applications running on these devices tend to be heavily dominated by I/O. Hailstorm tracks side effects like I/O in its type system using resource types. This choice allowed us to explore the design of a purely functional standalone language, in an area where it is more common to embed a functional core in an imperative shell. The language borrows the combinators of arrowized FRP, but has discrete-time semantics. The design of the full set of combinators is work in progress, driven by examples. So far, we have evaluated Hailstorm by writing standard examples from the literature (earthquake detection, a railway crossing system and various other clocked systems), and also running examples on the GRiSP embedded systems board, through generation of Erlang.},
+ booktitle = {Proceedings of the 22nd {International} {Symposium} on {Principles} and {Practice} of {Declarative} {Programming}},
+ publisher = {Association for Computing Machinery},
+ author = {Sarkar, Abhiroop and Sheeran, Mary},
+ year = {2020},
+ note = {event-place: Bologna, Italy},
+ keywords = {functional programming, compilers, embedded systems, IoT},
+ file = {Sarkar and Sheeran - 2020 - Hailstorm A Statically-Typed, Purely Functional L.pdf:/home/mrl/.local/share/zotero/storage/BKFJKGQP/Sarkar and Sheeran - 2020 - Hailstorm A Statically-Typed, Purely Functional L.pdf:application/pdf},
+}
+@inproceedings{10.1145/3281366.3281370,
+author = {Shibanai, Kazuhiro and Watanabe, Takuo},
+title = {Distributed Functional Reactive Programming on Actor-Based Runtime},
+year = {2018},
+isbn = {9781450360661},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/3281366.3281370},
+doi = {10.1145/3281366.3281370},
+abstract = {Reactive programming over a network is a challenging task because efficient elimination of temporary violations of data flow invariants, known as glitches, in a distributed setting is still an open issue. In this paper, we propose a method for constructing a distributed reactive programming system of which runtime guarantees the properties of single source glitch-freedom and the robustness against out-of-order messages. Based on the method, we developed a purely functional reactive programming language XFRP whose compiler produces Erlang code. Using some examples, we show that the proposed method is beneficial for constructing distributed reactive applications without suffering from inconsistencies.},
+booktitle = {Proceedings of the 8th ACM SIGPLAN International Workshop on Programming Based on Actors, Agents, and Decentralized Control},
+pages = {13–22},
+numpages = {10},
+keywords = {Distributed Functional Reactive Programming, Erlang, Glitch Freedom, Synchronization, Actor-Based Runtime System},
+location = {Boston, MA, USA},
+series = {AGERE 2018}
+}
+
+@inproceedings{suzuki_cfrp_2017,
+ address = {The University of The Philippines Cebu, Cebu City, The Philippines},
+ title = {{CFRP}: {A} {Functional} {Reactive} {Programming} {Language} for {Small}-{Scale} {Embedded} {Systems}},
+ isbn = {978-981-323-406-2 978-981-323-407-9},
+ shorttitle = {{CFRP}},
+ url = {http://www.worldscientific.com/doi/abs/10.1142/9789813234079_0001},
+ doi = {10.1142/9789813234079_0001},
+ language = {en},
+ urldate = {2022-03-02},
+ booktitle = {Theory and {Practice} of {Computation}},
+ publisher = {WORLD SCIENTIFIC},
+ author = {Suzuki, Kohei and Nagayama, Kanato and Sawada, Kensuke and Watanabe, Takuo},
+ month = dec,
+ year = {2017},
+ pages = {1--13},
+ file = {Suzuki et al. - 2017 - CFRP A Functional Reactive Programming Language f.pdf:/home/mrl/.local/share/zotero/storage/XHPSZCJH/Suzuki et al. - 2017 - CFRP A Functional Reactive Programming Language f.pdf:application/pdf},
+}
+
+
+@inproceedings{shibanai_distributed_2018,
+ address = {New York, NY, USA},
+ series = {{AGERE} 2018},
+ title = {Distributed {Functional} {Reactive} {Programming} on {Actor}-{Based} {Runtime}},
+ isbn = {978-1-4503-6066-1},
+ url = {https://doi.org/10.1145/3281366.3281370},
+ doi = {10.1145/3281366.3281370},
+ abstract = {Reactive programming over a network is a challenging task because efficient elimination of temporary violations of data flow invariants, known as glitches, in a distributed setting is still an open issue. In this paper, we propose a method for constructing a distributed reactive programming system of which runtime guarantees the properties of single source glitch-freedom and the robustness against out-of-order messages. Based on the method, we developed a purely functional reactive programming language XFRP whose compiler produces Erlang code. Using some examples, we show that the proposed method is beneficial for constructing distributed reactive applications without suffering from inconsistencies.},
+ booktitle = {Proceedings of the 8th {ACM} {SIGPLAN} {International} {Workshop} on {Programming} {Based} on {Actors}, {Agents}, and {Decentralized} {Control}},
+ publisher = {Association for Computing Machinery},
+ author = {Shibanai, Kazuhiro and Watanabe, Takuo},
+ year = {2018},
+ note = {event-place: Boston, MA, USA},
+ keywords = {Actor-Based Runtime System, Distributed Functional Reactive Programming, Erlang, Glitch Freedom, Synchronization},
+ pages = {13--22},
+ file = {Shibanai and Watanabe - 2018 - Distributed Functional Reactive Programming on Act.pdf:/home/mrl/.local/share/zotero/storage/UJ5IG7R4/Shibanai and Watanabe - 2018 - Distributed Functional Reactive Programming on Act.pdf:application/pdf},
+}
+
+@inproceedings{nilsson_functional_2002,
+ address = {New York, NY, USA},
+ series = {Haskell '02},
+ title = {Functional {Reactive} {Programming}, {Continued}},
+ isbn = {1-58113-605-6},
+ url = {https://doi.org/10.1145/581690.581695},
+ doi = {10.1145/581690.581695},
+ abstract = {Functional Reactive Programming (FRP) extends a host programming language with a notion of time flow. Arrowized FRP (AFRP) is a version of FRP embedded in Haskell based on the arrow combinators. AFRP is a powerful synchronous dataflow programming language with hybrid modeling capabilities, combining advanced synchronous dataflow features with the higher-order lazy functional abstractions of Haskell. In this paper, we describe the AFRP programming style and our Haskell-based implementation. Of particular interest are the AFRP combinators that support dynamic collections and continuation-based switching. We show how these combinators can be used to express systems with an evolving structure that are difficult to model in more traditional dataflow languages.},
+ booktitle = {Proceedings of the 2002 {ACM} {SIGPLAN} {Workshop} on {Haskell}},
+ publisher = {Association for Computing Machinery},
+ author = {Nilsson, Henrik and Courtney, Antony and Peterson, John},
+ year = {2002},
+ note = {event-place: Pittsburgh, Pennsylvania},
+ keywords = {functional programming, Haskell, domain-specific languages, FRP, hybrid modeling, synchronous dataflow languages},
+ pages = {51--64},
+ file = {Nilsson et al. - 2002 - Functional reactive programming, continued.pdf:/home/mrl/.local/share/zotero/storage/X79J47NP/Nilsson et al. - 2002 - Functional reactive programming, continued.pdf:application/pdf},
+}
+@inproceedings{10.1145/2661136.2661146,
+author = {Philips, Laure and De Roover, Coen and Van Cutsem, Tom and De Meuter, Wolfgang},
+title = {Towards Tierless Web Development without Tierless Languages},
+year = {2014},
+isbn = {9781450332101},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/2661136.2661146},
+doi = {10.1145/2661136.2661146},
+abstract = {Tierless programming languages enable developing the typical server, client and database tiers of a web application as a single mono-linguistic program. This development style is in stark contrast to the current practice which requires combining multiple technologies and programming languages. A myriad of tierless programming languages has already been proposed, often featuring a JavaScript-like syntax. Instead of introducing yet another, we advocate that it should be possible to develop tierless web applications in existing general-purpose languages. This not only reduces the complexity that developers are exposed to, but also precludes the need for new development tools. We concretize this novel approach to tierless programming by discussing requirements on its future instantiations. We explore the design space of the program analysis for determining and the program transformation for realizing the tier split respectively. The former corresponds to new adaptations of an old familiar, program slicing, for tier splitting. The latter includes several strategies for handling cross-tier function calls and data accesses. Using a prototype instantiation for JavaScript, we demonstrate the feasibility of our approach on an example web application. We conclude with a discussion of open questions and challenges for future research.},
+booktitle = {Proceedings of the 2014 ACM International Symposium on New Ideas, New Paradigms, and Reflections on Programming \& Software},
+pages = {69–81},
+numpages = {13},
+keywords = {tier splitting, program slicing, tierless programming, javascript},
+location = {Portland, Oregon, USA},
+series = {Onward! 2014}
+}
+
+@misc{hess_arduino-copilot_2020,
+ title = {arduino-copilot: {Arduino} programming in haskell using the {Copilot} stream {DSL}},
+ shorttitle = {arduino-copilot},
+ url = {//hackage.haskell.org/package/arduino-copilot},
+ urldate = {2020-02-14},
+ journal = {Hackage},
+ author = {Hess, Joey},
+ year = {2020},
+ file = {Snapshot:/home/mrl/.local/share/zotero/storage/PSHYKF52/arduino-copilot.html:text/html},
+}
+@INPROCEEDINGS{5558637,
+
+ author={Axelsson, Emil and Claessen, Koen and Dévai, Gergely and Horváth, Zoltán and Keijzer, Karin and Lyckegård, Bo and Persson, Anders and Sheeran, Mary and Svenningsson, Josef and Vajdax, András},
+
+ booktitle={Eighth ACM/IEEE International Conference on Formal Methods and Models for Codesign (MEMOCODE 2010)},
+
+ title={Feldspar: A domain specific language for digital signal processing algorithms},
+
+ year={2010},
+
+ volume={},
+
+ number={},
+
+ pages={169-178},
+
+ abstract={A new language, Feldspar, is presented, enabling high-level and platform-independent description of digital signal processing (DSP) algorithms. Feldspar is a pure functional language embedded in Haskell. It offers a high-level dataflow style of programming, as well as a more mathematical style based on vector indices. The key to generating efficient code from such descriptions is a high-level optimization technique called vector fusion. Feldspar is based on a low-level, functional core language which has a relatively small semantic gap to machine-oriented languages like C. The core language serves as the interface to the back-end code generator, which produces C. For very small examples, the generated code performs comparably to hand-written C code when run on a DSP target. While initial results are promising, to achieve good performance on larger examples, issues related to memory access patterns and array copying will have to be addressed.},
+
+ keywords={},
+
+ doi={10.1109/MEMCOD.2010.5558637},
+
+ ISSN={},
+
+ month={July},}
+
+@article{sheetz2009understanding,
+ title={Understanding developer and manager perceptions of function points and source lines of code},
+ author={Sheetz, Steven D and Henderson, David and Wallace, Linda},
+ journal={Journal of Systems and Software},
+ volume={82},
+ number={9},
+ pages={1540--1549},
+ year={2009},
+ publisher={Elsevier}
+}
+
+@article{fichera2017python,
+ title={A Python framework for programming autonomous robots using a declarative approach},
+ author={Fichera, Loris and Messina, Fabrizio and Pappalardo, Giuseppe and Santoro, Corrado},
+ journal={Science of Computer Programming},
+ volume={139},
+ pages={36--55},
+ year={2017},
+ publisher={Elsevier}
+}
+
+@inproceedings{balat2006ocsigen,
+ title={Ocsigen: Typing web interaction with objective caml},
+ author={Balat, Vincent},
+ booktitle={Proceedings of the 2006 Workshop on ML},
+ pages={84--94},
+ year={2006}
+}
+
+@inproceedings{bjornson2010composing,
+ title={Composing reactive GUIs in F\# using WebSharper},
+ author={Bjornson, Joel and Tayanovskyy, Anton and Granicz, Adam},
+ booktitle={Symposium on Implementation and Application of Functional Languages},
+ pages={203--216},
+ year={2010},
+ organization={Springer}
+}
+
+@book{strack2015getting,
+ title={Getting Started with Meteor. js JavaScript Framework},
+ author={Strack, Isaac},
+ year={2015},
+ publisher={Packt Publishing Ltd}
+}
+
+@incollection{hall1993glasgow,
+ title={The Glasgow Haskell compiler: a retrospective},
+ author={Hall, Cordelia and Hammond, Kevin and Partain, Will and Peyton Jones, Simon L and Wadler, Philip},
+ booktitle={Functional Programming, Glasgow 1992},
+ pages={62--71},
+ year={1993},
+ publisher={Springer}
+}
+
+@misc{diffmicro,
+ title = "MicroPython Differences from CPython",
+ author = "Micropython Official Website",
+ year = "2022",
+ note = "https://docs.micropython.org/en/latest/genrst/index.html",
+}
+
+@article{weisenburger2020survey,
+ title={A survey of multitier programming},
+ author={Weisenburger, Pascal and Wirth, Johannes and Salvaneschi, Guido},
+ journal={ACM Computing Surveys (CSUR)},
+ volume={53},
+ number={4},
+ pages={1--35},
+ year={2020},
+ publisher={ACM New York, NY, USA}
+}
+
+@inproceedings {203628,
+author = {Manos Antonakakis and Tim April and Michael Bailey and Matt Bernhard and Elie Bursztein and Jaime Cochran and Zakir Durumeric and J. Alex Halderman and Luca Invernizzi and Michalis Kallitsis and Deepak Kumar and Chaz Lever and Zane Ma and Joshua Mason and Damian Menscher and Chad Seaman and Nick Sullivan and Kurt Thomas and Yi Zhou},
+title = {Understanding the Mirai Botnet},
+booktitle = {26th USENIX Security Symposium (USENIX Security 17)},
+year = {2017},
+isbn = {978-1-931971-40-9},
+address = {Vancouver, BC},
+pages = {1093--1110},
+url = {https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/antonakakis},
+publisher = {USENIX Association},
+month = aug,
+}
+
+@inproceedings{herwig_measurement_2019,
+ address = {San Diego, CA, USA},
+ title = {Measurement and {Analysis} of {Hajime}, a {Peer}-to-peer {IoT} {Botnet}},
+ isbn = {1-891562-55-X},
+ url = {https://par.nsf.gov/biblio/10096257},
+ doi = {10.14722/ndss.2019.23488},
+ booktitle = {Network and {Distributed} {Systems} {Security} ({NDSS}) {Symposium} 2019},
+ author = {Herwig, Stephen and Harvey, Katura and Hughey, George and Roberts, Richard and Levin, Dave},
+ year = {2019},
+ pages = {15},
+ file = {Herwig et al. - Measurement and Analysis of Hajime, a Peer-to-peer.pdf:/home/mrl/.local/share/zotero/storage/YFB8C8CU/Herwig et al. - Measurement and Analysis of Hajime, a Peer-to-peer.pdf:application/pdf},
+}
+@article{10.1145/3437537,
+author = {Alhirabi, Nada and Rana, Omer and Perera, Charith},
+title = {Security and Privacy Requirements for the Internet of Things: A Survey},
+year = {2021},
+issue_date = {February 2021},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+volume = {2},
+number = {1},
+issn = {2691-1914},
+url = {https://doi.org/10.1145/3437537},
+doi = {10.1145/3437537},
+abstract = {The design and development process for internet of things (IoT) applications is more complicated than that for desktop, mobile, or web applications. First, IoT applications require both software and hardware to work together across many different types of nodes with different capabilities under different conditions. Second, IoT application development involves different types of software engineers such as desktop, web, embedded, and mobile to work together. Furthermore, non-software engineering personnel such as business analysts are also involved in the design process. In addition to the complexity of having multiple software engineering specialists cooperating to merge different hardware and software components together, the development process requires different software and hardware stacks to be integrated together (e.g., different stacks from different companies such as Microsoft Azure and IBM Bluemix). Due to the above complexities, non-functional requirements (such as security and privacy, which are highly important in the context of the IoT) tend to be ignored or treated as though they are less important in the IoT application development process. This article reviews techniques, methods, and tools to support security and privacy requirements in existing non-IoT application designs, enabling their use and integration into IoT applications. This article primarily focuses on design notations, models, and languages that facilitate capturing non-functional requirements (i.e., security and privacy). Our goal is not only to analyse, compare, and consolidate the empirical research but also to appreciate their findings and discuss their applicability for the IoT.},
+journal = {ACM Trans. Internet Things},
+month = {feb},
+articleno = {6},
+numpages = {37},
+keywords = {design principles, software design tools, Internet of Things, non functional requirements, notation, software engineering}
+}
+
+@phdthesis{wijkhuizen_security_2018,
+ address = {Nijmegen},
+ type = {Bachelor's {Thesis}},
+ title = {Security analysis of the {iTasks} framework},
+ url = {http://www.ru.nl/publish/pages/769526/arjan_oortgiese.pdf},
+ language = {English},
+ urldate = {2017-04-08},
+ school = {Radboud University},
+ author = {Wijkhuizen, Mark},
+ year = {2018},
+ file = {Wijkhuizen - 2018 - Security analysis of the iTasks framework.pdf:/home/mrl/.local/share/zotero/storage/AWFT6PGL/Wijkhuizen - 2018 - Security analysis of the iTasks framework.pdf:application/pdf},
+}
+@inproceedings{Steenvoorden2019tophat,
+author = {Steenvoorden, Tim and Naus, Nico and Klinik, Markus},
+title = {TopHat: A Formal Foundation for Task-Oriented Programming},
+year = {2019},
+isbn = {9781450372497},
+publisher = {Association for Computing Machinery},
+address = {New York, NY, USA},
+url = {https://doi.org/10.1145/3354166.3354182},
+doi = {10.1145/3354166.3354182},
+booktitle = {Proceedings of the 21st International Symposium on Principles and Practice of Declarative Programming},
+articleno = {17},
+numpages = {13},
+location = {Porto, Portugal},
+series = {PPDP '19}
+}
+
+
+
+
repositories / phd-thesis.git / commitdiff
