@misc{lubbers_htask_2022,
title = {{hTask}},
- url = {https://gitlab.com/mlubbers/acsds},
+ url = {https://gitlab.com/mlubbers/hTask},
urldate = {2022-10-07},
author = {Lubbers, Mart},
year = {2022},
Deeply embedded languages represent their language constructs as data and the semantics are functions on it.
As a result, the language constructs are embedded in the semantics, hence adding new language constructs is laborious where adding semantics is trouble free.
- This paper shows that by abstracting the semantics functions in deep embedding to type classes, it is possible to easily add language constructs as well.
+ This chapter shows that by abstracting the semantics functions in deep embedding to type classes, it is possible to easily add language constructs as well.
So-called classy deep embedding results in \glspl{DSL} that are extensible both in language constructs and in semantics while maintaining a concrete abstract syntax tree.
Additionally, little type-level trickery or complicated boilerplate code is required to achieve this.
\end{chapterabstract}
The semantics of the \gls{DSL} have to be combined and must hold some kind of state or context, so that structural information is not lost \citep{kiselyov_typed_2012}.
\subsection{Research contribution}
-This paper shows how to apply the technique observed in tagless-final embedding to deep embedding.
+This chapter shows how to apply the technique observed in tagless-final embedding to deep embedding.
The presented basic technique, christened \emph{classy deep embedding}, does not require advanced type system extensions to be used.
However, it is suitable for type system extensions such as \glspl{GADT}.
-While this paper is written as a literate
+While this chapter is written as a literate
\Gls{HASKELL} \citep{peyton_jones_haskell_2003} program using some minor extensions provided by \gls{GHC} \citep{ghc_team_ghc_2021}, the idea is applicable to other languages as well\footnotemark.
\footnotetext{Lubbers, M. (2021): Literate Haskell/lhs2\TeX{} source code of the paper ``Deep Embedding
with Class'': TFP 2022.\ DANS.\ \url{https://doi.org/10.5281/zenodo.5081386}.}
\Citet{loh_open_2006} proposed a language extension that allows open data types and open functions, i.e.\ functions and data types that can be extended with more cases later on.
They hinted at the possibility of using type classes for open functions but had serious concerns that pattern matching would be crippled because constructors are becoming types, thus ultimately becoming impossible to type.
-In contrast, this paper shows that pattern matching is easily attainable---albeit using dynamic types---and that the terms can be typed without complicated type system extensions.
+In contrast, this chapter shows that pattern matching is easily attainable---albeit using dynamic types---and that the terms can be typed without complicated type system extensions.
A technique similar to classy deep embedding was proposed by \citet{najd_trees_2017} to tackle a slightly different problem, namely that of reusing a data type for multiple purposes in a slightly different form.
For example to decorate the abstract syntax tree of a compiler differently for each phase of the compiler.
However, data types defined in the host language are not automatically available in the embedded language.
To do so, all the operations on the data type must be ported to the \gls{EDSL} resulting in a lot of boilerplate.
- This paper shows that by using metaprogramming, all first-order user-defined data types can be automatically made first class in shallow \glspl{EDSL}.
+ This chapter shows that by using metaprogramming, all first-order user-defined data types can be automatically made first class in shallow \glspl{EDSL}.
We show this by providing an implementation in \gls{TH} for a typical \gls{DSL} with two different semantics.
Furthermore, we show that by utilising quasiquotation, there is hardly any burden on the syntax.
- Finally, the paper also serves as a gentle introduction to \gls{TH}.
+ Finally, the chapter also serves as a gentle introduction to \gls{TH}.
\end{chapterabstract}
\section{Introduction}
Quasiquotation is a metaprogramming mechanism that allows entering verbatim code for which a---possibly user defined---translation is used to convert the verbatim code to host language \gls{AST} nodes.
Metaprogramming allows functions to be added to the program at compile time based on the structure of user-defined data types.
-\subsection{Contributions of the paper}
-This paper shows that with the use of metaprogramming, all first-order user-defined data types can automatically be made first class for shallow \glspl{EDSL}.
+\subsection{Contributions}
+This chapter shows that with the use of metaprogramming, all first-order user-defined data types can automatically be made first class for shallow \glspl{EDSL}.
It does so by providing an implementation in \gls{TH} for a typical \gls{DSL} with two different semantics: an interpreter and a pretty printer.
Furthermore, we show that by utilising quasiquotation, there is hardly any burden on the syntax.
-Finally, the paper also serves as a gentle introduction to \gls{TH} and reflects on the process of using \gls{TH}.
+Finally, the chapter also serves as a gentle introduction to \gls{TH} and reflects on the process of using \gls{TH}.
\section{Tagless-final embedding}
Tagless-final embedding is an upgrade to standard shallow embedding achieved by lifting all language construct functions to type classes.
\Citet{willis_staged_2020} used \gls{TTH} to remove the overhead of parsing combinators.
\section{Discussion}
-This paper aims to be twofold, first, it shows how to inherit data types in a \gls{DSL} as first-class citizens by generating the boilerplate at compile time using \gls{TH}.
+This chapter aims to be twofold, first, it shows how to inherit data types in a \gls{DSL} as first-class citizens by generating the boilerplate at compile time using \gls{TH}.
Secondly, it introduces the reader to \gls{TH} by giving an overview of the literature in which \gls{TH} is used and provides a gentle introduction by explaining the case study.
\Gls{FP} languages are especially suitable for embedding \glspl{DSL} but adding user-defined data types is still an issue.
Firstly, edge devices can be seen as simple resources, thus accessed through \glspl{SDS}.
The second view is that edge devices contain miniature \gls{TOP} systems in itself.
The individual components in the miniature systems, the tasks, the \glspl{SDS}, are, in the eventual execution, connected to the main system.
+\todo{hier plaatje uit 6?: nee}
\subsection{The iTask system}
The concept of \gls{TOP} originated from the \gls{ITASK} framework, a declarative language and \gls{TOP} engine for defining interactive multi-user distributed web applications.
The \gls{ITASK} system is implemented as an \gls{EDSL} in the programming language \gls{CLEAN}\footnote{\Cref{chp:clean_for_haskell_programmers} contains a guide for \gls{CLEAN} tailored to \gls{HASKELL} programmers.} \citep{plasmeijer_itasks:_2007,plasmeijer_task-oriented_2012}.
-It has been under development for over fifteen years and has proven itself through use in industry for some time now as well \citep{top_software_viia_2023}.
+It has been under development for over fifteen years and has proven itself through use in industry for some time now as well.
+For example, it is the main language of VIIA, an advanced application for monitoring coasts \citep{top_software_viia_2023}.
From the structural properties of the data types and the current status of the work to be done, the entire \gls{UI} is automatically generated.
Browsers are powering \gls{ITASK}'s presentation layer.
The framework is built on top of standard web techniques such as JavaScript, HTML, and {CSS}.
The \gls{MTASK} device is connected using \cleaninline{withDevice} at \cref{lst:intro_withdevice}.
Once connected, the \cleaninline{intBlink} task is sent to the device (\cref{lst:intro_liftmtask}) and, in parallel, a web editor is shown that updates the value of the interval \gls{SDS} (\cref{lst:intro_editor,fig:intro_blink_int}).
To allow terminating of the task, the \gls{ITASK} task ends with a sequential operation that returns a constant value when the button is pressed, making the task stable.
+\todo{foto device+led?}
\cleaninputlisting[float={!ht},firstline=10,lastline=18,numbers=left,caption={The \gls{ITASK} code for the interactive blinking application.},label={lst:intro_blink}]{lst/blink.icl}
\subsection{\Fullref{prt:dsl}}
The \gls{MTASK} system is an \gls{EDSL} and during the development of it, several novel basal techniques for embedding \glspl{DSL} in \gls{FP} languages have been found.
This paper-based episode contains the following papers:
+\todo{papers met bibitem doen? of conferentie noemen.}
\begin{enumerate}
\item \emph{Deep Embedding with Class} \citep*{lubbers_deep_2022} is the basis for \cref{chp:classy_deep_embedding}.
It shows a novel deep embedding technique for \glspl{DSL} where the resulting language is extendible both in constructs and in interpretation just using type classes and existential data types.
\Cref{sec:classy_reprise} was added after publication and contains a (yet) unpublished extension of the embedding technique for reducing the required boilerplate at the cost of requiring some advanced type system extensions.
\item \emph{First-\kern-1ptClass Data Types in Shallow Embedded Domain-Specific Languages} \citep*{lubbers_first-class_2022}\label{enum:first-class} is the basis for \cref{chp:first-class_datatypes}.
It shows how to inherit data types from the host language in \glspl{EDSL} using metaprogramming by providing a proof-of-concept implementation using \gls{HASKELL}'s metaprogramming system: \glsxtrlong{TH}.
- The paper also serves as a gentle introduction to, and contains a thorough literature study on \glsxtrlong{TH}.
+ The chapter also serves as a gentle introduction to, and contains a thorough literature study on \glsxtrlong{TH}.
\end{enumerate}
%\paragraph{In preparation}
\subsection{\Fullref{prt:tvt}}
\Cref{prt:tvt} is based on a journal paper that quantitatively and qualitatively compares traditional \gls{IOT} architectures with \gls{TOP} \gls{IOT} architectures.
-This chapter is based on the conference paper and a journal paper extending it:
\begin{enumerate}[resume]
- \item \emph{Tiered versus Tierless \glsxtrshort{IOT} Stacks: Comparing Smart Campus Software Architectures} \citep*{lubbers_tiered_2020}\footnote{This work was partly funded by the 2019 Radboud-Glasgow Collaboration Fund.}\label{enum:iot20} compares traditional tiered programming to tierless architectures by comparing two implementations of a smart-campus application.
\item \emph{Could Tierless Programming Reduce IoT Development Grief?} \citep*{lubbers_could_2022}
is an extended version of paper~\ref{enum:iot20}.
It compares programming traditional tiered architectures to tierless architectures by illustrating a qualitative and a quantitative four-way comparison of a smart-campus application.
+ \item \emph{Tiered versus Tierless \glsxtrshort{IOT} Stacks: Comparing Smart Campus Software Architectures} \citep*{lubbers_tiered_2020}\footnote{This work was partly funded by the 2019 Radboud-Glasgow Collaboration Fund.}\label{enum:iot20} compares traditional tiered programming to tierless architectures by comparing two implementations of a smart-campus application.
\end{enumerate}
\paragraph{Contribution:}
\def\bibfont{\footnotesize}
%\setcitestyle{numbers}
%\bibliographystyle{alpha}
-\bibliographystyle{myabbrvnat}
+\bibliographystyle{\subfix{myabbrvnat}}
\usepackage{ragged2e}
\apptocmd{\thebibliography}{\RaggedRight}{}{}
}\end{lstArduino}
\subsection{Multitasking in mTask}
-In contrast to the \arduinoinline{delay} function in \gls{ARDUINO}, \gls{MTASK}'s \cleaninline{delay} \emph{task} does not block the execution.
+In \gls{MTASK}, expressions are eagerly evaluated in an interpreter and tasks are executed by small-step rewrite rules.
+In between these rewrite steps, other tasks are be executed and communication is handled.
+Consequently, and in contrast to \gls{ARDUINO}, the \cleaninline{delay} task in \gls{MTASK} does not block the execution.
It has no observable value until the target waiting time has passed, and is thence \emph{stable}.
As there is no global state, the function is parametrised with the current status, the pin to blink and the waiting time.
With a parallel combinator, tasks are executed at the same time.
Programming them happens through compiled firmwares using low-level imperative programming languages.
Due to the lack of an \gls{OS}, writing applications that perform multiple tasks at the same time is error-prone, becomes complex, and requires a lot of boilerplate such as manual scheduling code.
With the \gls{MTASK} system, a \gls{TOP} programming language for \gls{IOT} edge devices, this limitation can be overcome.
-Since much domain-specific knowledge is built into the language and \gls{RTS}, the hardware requirements can be kept relatively low while maintaining a high abstraction level.
+Since a lot domain-specific knowledge is built into the language and \gls{RTS}, the hardware requirements can be kept relatively low while maintaining a high abstraction level.
Furthermore, the programs are automatically integrated with \gls{ITASK}, a \gls{TOP} system for creating interactive distributed web applications, allowing for data sharing, task coordination, and dynamic construction of tasks.
+\todo[inline]{
+This makes it easy to create interactive applications modelling collaboration between end-users and edge devices.
+}
The following chapters of this monograph thoroughly introduce all aspects of the \gls{MTASK} system.
First the language setup and interface are shown in \cref{chp:mtask_dsl}.
Devices are connected to the system using the \cleaninline{withDevice} function (see \cref{sec:withdevice}).
Using \cleaninline{liftmTask}, \gls{MTASK} tasks are lifted to a device (see \cref{sec:liftmtask}).
\glspl{SDS} from \gls{ITASK} are lowered to the \gls{MTASK} device using \cleaninline{lowerSds} (see \cref{sec:liftsds}).
+\todo[inline]{mTask device\textsubscript{n} naar hfstk 5? Uitleg over taken en sensoren en \ldots? evt.\ zelfs naar intro hmmm?}
\begin{figure}
\centering
\end{tabular}
\end{table}
-\footnote{In \gls{ARDUINO} \ccpp{} this usually equals a \cinline{long}.}
+\footnotetext{In \gls{ARDUINO} \ccpp{} this usually equals a \cinline{long}.}
\Cref{lst:constraints} contains the definitions for the auxiliary types and type constraints (such as \cleaninline{type} and \cleaninline{basicType}) that are used to construct \gls{MTASK} expressions.
\begin{lstClean}[caption={Classes and class collections for the \gls{MTASK} language.},label={lst:constraints}]
\end{lstClean}
\section{Interpretations}
-This section describes all the interpretations that the \gls{MTASK} language has.
+\todo[inline]{Iets meer uitleg over waarom dit zo handig is}
+This section describes all the interpretations that the \gls{MTASK} language has to offer.
Not all these interpretations are necessarily \gls{TOP} engines, i.e.\ not all the interpretations execute the resulting tasks.
Some may perform an analysis over the program or typeset the program.
I.e.\ some components---for example the \gls{RTS} on the microcontroller that executes the tasks---is largely unaware of the other components in the system, and it is executed on a completely different architecture.
The \gls{MTASK} language is based on a simply-typed $\lambda$-calculus with support for some basic types, arithmetic operations, and function definitions.
As the language is a \gls{TOP} language, it is also enriched with a task language (see \cref{sec:top}).
+\todo[inline]{Duidelijker maken dat het at compile time gebeurt en niet at run time.}
\section{Conclusion}
This chapter gave an overview of the complete \gls{MTASK} \gls{DSL}.
The language is an enriched lambda calculus as a host language.
It provides language constructs for arithmetic expressions, conditionals, functions, but also non-interactive basic tasks, task combinators, peripheral support, and integration with \gls{ITASK}.
Terms in the language are just interfaces and can be interpreted by one or more interpretations.
+\todo[inline]{Which can be used to\ldots}
The most important interpretation of the language is the byte code compiler.
+\todo[inline]{That compiles the terms to byte code at compiletime and not run time}
\input{subfilepostamble}
\end{document}
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 \citep{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}.
+This chapter 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 \citep{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}.\label{enum:c1}
\end{description}
-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.
+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 chapter.
\begin{description}[style=sameline]
\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 web applications \citep{mazzei2018full}. That is, the developer must correctly use multiple languages that have different paradigms, i.e.\ manage significant \emph{semantic friction} \citep{ireland_classification_2009}. For example the \gls{PWS} developer must integrate components written in seven languages with two paradigms (\cref{sec_t4t:interoperation}).
\section{Task-oriented and \IOT{} programming in 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.
+To make this chapter 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 \gls{FP} language similar to \gls{HASKELL}: both languages are pure and non-strict \citep{achten_clean_2007}.
A key difference is how state is handled: \gls{HASKELL} typically embeds stateful actions in the \haskellinline{IO} Monad \citep{peyton_jones_imperative_1993,wiki:IO}.
\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.
+This chapter 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}.
repositories / phd-thesis.git / commitdiff