.
[phd-thesis.git] / intro / introduction.tex
index 53d3b15..3897350 100644 (file)
@@ -3,7 +3,7 @@
 \input{subfilepreamble}
 
 \begin{document}
-\chapter{Introduction}%
+\chapter{Prelude}%
 \label{chp:introduction}
 
 \begin{chapterabstract}
@@ -78,7 +78,7 @@ Writing idiomatic domain-specific code in an \gls{DSL} is easy but this may come
 \begin{figure}[ht]
        \centering
        \includestandalone{hyponymy_of_dsls}
-       \caption{Hyponymy of \glspl{DSL} (adapted from \citet[pg.\ 2]{mernik_extensible_2013})}%
+       \caption{Hyponymy of \glspl{DSL} (adapted from \citet[\citepage{2}]{mernik_extensible_2013})}%
        \label{fig:hyponymy_of_dsls}
 \end{figure}
 
@@ -90,7 +90,7 @@ Examples of standalone \glspl{DSL} are regular expressions, make, yacc, XML, SQL
 
 A dichotomous approach is embedding the \gls{DSL} in a host language, i.e.\ \glspl{EDSL}~\citep{hudak_modular_1998}.
 By defining the language as constructs in the host language, much of the machinery is inherited and the cost of creating embedded languages is very low.
-There is more linguistic reuse~\cite{krishnamurthi_linguistic_2001}.
+There is more linguistic reuse \citep{krishnamurthi_linguistic_2001}.
 There are however two sides to the this coin.
 If the syntax of the host language is not very flexible, the syntax of the \gls{DSL} may become clumsy.
 Furthermore, errors shown to the programmer may be larded with host language errors, making it difficult for a non-expert of the host language to work with the \gls{DSL}.
@@ -129,7 +129,7 @@ This approach to software development is called \gls{TOSD}~\citep{wang_maintaini
                \includestandalone{tosd}
                \caption{\Gls{TOSD} approach.}
        \end{subfigure}
-       \caption{Separation of concerns in a traditional setting and in \gls{TOSD} (adapted from~\cite[pg.\ 20]{wang_maintaining_2018}).}%
+       \caption{Separation of concerns in a traditional setting and in \gls{TOSD} (adapted from \citet[\citesection{1}]{wang_maintaining_2018}).}%
        \label{fig:tosd}
 \end{figure}
 
@@ -161,12 +161,11 @@ While \gls{ITASK} conceived \gls{TOP}, it is not the only \gls{TOP} language.
 \citet{piers_task-oriented_2016} created \textmu{}Task, a \gls{TOP} language for specifying non-interruptible embedded systems implemented as an \gls{EDSL} in \gls{HASKELL}.
 \citet{van_gemert_task_2022} created LTasks, a \gls{TOP} language for interactive terminal applications implemented in LUA, a dynamically typed imperative language.
 \citet{lijnse_toppyt_2022} created Toppyt, a \gls{TOP} language based on \gls{ITASK}, implemented in \gls{PYTHON}, but designed to be simpler and smaller.
-Finally there is \gls{MTASK}, \gls{TOP} language designed for defining workflow for \gls{IOT} devices~\cite{koopman_task-based_2018}.
+Finally there is \gls{MTASK}, \gls{TOP} language designed for defining workflow for \gls{IOT} devices \citep{koopman_task-based_2018}.
 It is written in \gls{CLEAN} as an \gls{EDSL} fully integrated with \gls{ITASK} and allows the programmer to define all layers of an \gls{IOT} system from a single source.
 
 \section{Outline}
-\todo[inline]{uitbreiden}
-On Wikipedia, a rhapsody is defined as follows~\citep{wikipedia_contributors_rhapsody_2022}:
+Wikipedia defines a rhapsody as follows \citep{wikipedia_contributors_rhapsody_2022}:
 \begin{quote}
        A \textbf{rhapsody} in music is a one-movement work that is episodic yet integrated, free-flowing in structure, featuring a range of highly contrasted moods, colour, and tonality. An air of spontaneous inspiration and a sense of improvisation make it freer in form than a set of variations.
 \end{quote}
@@ -180,22 +179,26 @@ This movement is a cumulative---paper-based---movement that focusses on techniqu
 After reading the first chapter, subsequent chapters in this movement are readable independently.
 
 \subsubsection*{\fullref{chp:dsl_embedding_techniques}}
-This chapter shows the basic \gls{DSL} embedding techniques and compares the properties of several embedding methods.
-This chapter is not based on a paper and written as a extra background material for the subsequent chapters in the movement.
+This chapter outlines the basic \gls{DSL} embedding techniques and compares the properties of several embedding methods.
+By example, it provides intuition on shallow embedding, including tagless-final embedding and deep embedding, including deep embedding with \acrshortpl{GADT}.
+It is not based on a paper but written as gentle background material for the subsequent chapters in the movement.
 
 \subsubsection*{\fullref{chp:classy_deep_embedding}}
-This chapter is based on the paper: \bibentry{lubbers_deep_2022}\todo{change in-press when published}.
+This chapter is based on the paper: \citeentry{lubbers_deep_2022}\todo{change in-press when published}
 
 While supervising \citeauthor{amazonas_cabral_de_andrade_developing_2018}'s \citeyear{amazonas_cabral_de_andrade_developing_2018} Master's thesis, focussing on an early version of \gls{MTASK}, a seed was planted for a novel deep embedding technique for \glspl{DSL} where the resulting language is extendible both in constructs and in interpretation using type classes and existential data types.
 Slowly the ideas organically grew to form the technique shown in the paper.
 
 The research from this paper and writing the paper was solely performed by me.
 \Cref{sec:classy_reprise} was added after publication and contains a (yet) unpublished extension of the embedding technique.
+The related work section (\cref{sec:cde:related}) is also brought up to date.\todo{weghalen als dit niet het geval is}
 
 \subsubsection*{\fullref{chp:first-class_datatypes}}
-This chapter is based on the paper: \bibentry{lubbers_first-class_2022}\todo{change when accepted}.
+This chapter is based on the paper: \citeentry{lubbers_first-class_2022}\todo{change when accepted}
 
-It shows how to inherit data types from the host language in \glspl{EDSL} using metaprogramming.
+When embedding \glspl{DSL} many features of the host language can be inherited.
+However, data types from the host are not first-class citizens, in order to use the datatypes, access functions need to be created in the \gls{DSL} resulting in boilerplate.
+This paper shows how to inherit data types from the host language in \glspl{EDSL} using metaprogramming by generating the boilerplate required.
 
 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.
 
@@ -203,12 +206,12 @@ The research in this paper and writing the paper was performed by me, though the
 This part is a monograph focussing on \glspl{TOP} for the \gls{IOT} and hence are the chapters best read in order.
 The monograph is compiled from the following papers and revised lecture notes.
 
-\newcommand{\citeentry}[1]{\begin{NoHyper}\bibentry{#1}\end{NoHyper}. \citep{#1}}
 \begin{itemize}
        \item \citeentry{koopman_task-based_2018}
 
-               This was the initial \gls{TOP}/\gls{MTASK} paper.
-               Pieter Koopman wrote it, I helped with the software and research.
+               While an imperative predecessor of \gls{MTASK} was conceived in 2017 \citep{plasmeijer_shallow_2016}, this paper showed the first \gls{TOP} version of \gls{MTASK}.
+               It shows the design of the language and three intepretations: pretty printing, simulation using \gls{ITASK} and \gls{C} code generation.
+               Pieter Koopman wrote the paper, I helped with the software and research.
        \item \citeentry{lubbers_task_2018}
                
                This paper was an extension of my Master's thesis~\citep{lubbers_task_2017}.