Within functions, the strict let (\cleaninline{#!}) is used to force evaluate an expression, in \gls{HASKELL} \haskellinline{seq} or \haskellinline{\$!} is used for this.
\subsection{Uniqueness typing}
-Types in \gls{CLEAN} may be \emph{unique}, which means that they cannot be shared \citep{barendsen_uniqueness_1996}.
+Types in \gls{CLEAN} may be \emph{unique}, which means that instances of the type cannot be shared \citep{barendsen_uniqueness_1996}.
The uniqueness type system allows the compiler to generate efficient code because unique data structures can be destructively updated.
Furthermore, uniqueness typing serves as a model for side effects as well \citep{achten_high_1993,achten_ins_1995}.
\Gls{CLEAN} uses the \emph{world-as-value} paradigm where \cleaninline{World} represents the external environment and is always unique \citep{backus_introduction_1990}.
\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
+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
, port :: Int
, pingTimeout :: ?Int
}
-:: MQTTSettings =
+:: MQTTSettings =
{ host :: String
, port :: Int
, mcuId :: String
, serverId :: String
, auth :: MQTTAuth
}
-:: TTYSettings = {
- devicePath :: String,
- baudrate :: BaudRate,
- bytesize :: ByteSize,
- parity :: Parity,
- stop2bits :: Bool,
- xonxoff :: Bool,
- sleepTime :: Int
+:: TTYSettings =
+ { devicePath :: String
+ , baudrate :: BaudRate
+ , bytesize :: ByteSize
+ , parity :: Parity
+ , stop2bits :: Bool
+ , xonxoff :: Bool
+ , sleepTime :: Int
}
\end{lstClean}
\ifSubfilesClassLoaded{\chapter*{Summary}}{\chapter{Summary}}%
\label{chp:summary}%
\glsresetall%
+\todo[inline]{
+eigenlijk zouden de eerste zinnen van de alinea's in je samenvatting zouden de samenvatting van je samenvatting moeten zijn.
+}
+
The number of computers around us is growing exponentially, compounding the complexity of the systems in which they operate.
Many of these computers are \emph{edge devices} operating in \gls{IOT} systems.
Within these orchestrations of computers, they interact with the environment using sensors and actuators.
Edge devices often use low-cost microcontrollers designed for embedded applications.
They have little memory, unhurried processors, and are slow in communication but are also small and energy efficient.
-Programming \gls{IOT} systems is complex since they are dynamic, interactive, distributed, collaborative, multi-tiered, and multitasking in nature.
+Programming \gls{IOT} systems is complex since they are dynamic, interactive, distributed, collaborative, multi-tiered, and multitasking in nature.\todo[inline]{Dit eerste zin maken?}
The complexity is increased further by semantic friction that arises through different hardware and software characteristics between tiers.
A solution is found in \gls{TOP}.
+\todo[inline]{Dit is nog niet erg specifiek voor dit werk. De eerste zin is prima. Verder zijn er volgens mij twee dingen van belang: high level focus op de taken die gedaan moeten woredn en alle code uit een source genereren (tierless).}
%A solution is found in the declarative programming paradigm \gls{TOP}.%, a declarative programming paradigm.
In \gls{TOP}, the main building blocks are tasks, an abstract representation of work.
During execution, the current value of the task is observable, and other tasks can act upon it.
However, it is not straightforward to run \gls{TOP} systems on resource-constrained edge devices.
This dissertation demonstrates how to orchestrate complete \gls{IOT} systems using \gls{TOP}.
+\todo[inline]{Eerste zin moet al het woord DSL bevatten}
First, I present advanced \gls{DSL} embedding techniques.
Then \gls{MTASK} is shown, a \gls{TOP} \gls{DSL} for \gls{IOT} edge devices, embedded in \gls{ITASK}.
Tasks are constructed and compiled at run time.
This allows tasks to be tailor-made for the current work requirements.
The compiled task is sent to the device for interpretation.
For a device to be used in an \gls{MTASK} system, it is programmed once with a lightweight domain-specific \gls{OS}.
+\todo[inline]{Waar, maar erg op de tecniek. Wat je er aan hebt lijkt me belangrijker.}
This \gls{OS} executes tasks in an energy-efficient way and automates all communications and data sharing.
-All aspects of the \gls{MTASK} system are shown: example applications, language design, implementation details, integration with \gls{ITASK}, and green computing facilities.
+All aspects of the \gls{MTASK} system are shown: example applications, language design, implementation details, integration with \gls{ITASK}, and green computing facilities such as automatic sleeping.
When using \gls{MTASK} in conjunction with \gls{ITASK}, entire \gls{IOT} systems are programmed tierlessly from a single source, language, paradigm, high abstraction level, and type system.
Many problems such as semantic friction; maintainability and robustness issues; and interoperation safety are mitigated when using tierless programming.
+\todo[inline]{episode III mist eigenlijk nog.\ vergelijking met de traditionele IoT implementatie heeft laten zien dat dit inderdaad veel korter en veiliger is.}
%This is a summary of 350--400 words.
\end{document}
}
@article{tratt_domain_2008,
- title = {Domain Specific Language Implementation via Compile-Time Meta-Programming},
+ title = {Domain Specific Language Implementation via Compile\hskip0pt-\hskip0pt Time Meta\hskip0pt-\hskip0pt Programming},
volume = {30},
issn = {0164-0925},
doi = {10.1145/1391956.1391958},
publisher = {Springer}
}
-@Misc{ diffmicro,
+@online{ diffmicro,
title = "MicroPython Differences from CPython",
author = {{Micropython Team}},
- year = "2022",
- note = "https://docs.micropython.org/en/latest/genrst/index.html"
+ date = "2022",
+ url = {https://docs.micropython.org/en/latest/genrst/index.html}
}
@Article{ weisenburger2020survey,
These small and cheap computers do not have powerful hardware but are energy efficient and support many sensors and actuators.
While the term \gls{IOT} has already been known for almost thirty years, only recently, the exponential growth of the number of \gls{IOT} edge devices is really ramping up.
Programming \gls{IOT} systems is very complex because each layer of the system is built with different computers, hardware architectures, programming languages, programming paradigms, and abstraction levels.
-This generates a lot of semantic friction.
+This generates a lot of semantic friction.\todo[inline]{benoem ook de andere problemen. Geen over all type check om correcte samenwerking te garanderen.}
Furthermore, \gls{IOT} systems become convoluted because they are dynamic, multi-tiered, multi-user, multitasking, interactive, distributed, and collaborative in nature.
\Gls{TOP} proves a suitable programming paradigm that allows the declarative specification of exactly such systems.
However, edge devices are often too computationally restricted to be able to run a full-fledged \gls{TOP} system such as \gls{ITASK}.
The dissertation is structured as a purely functional rhapsody in three episodes.
In order to get \gls{TOP} to resource-constrained edge devices we use special tools: \glspl{DSL}.
-The dissertation shows several techniques for creating \glspl{EDSL}.
-Then it shows a tool, \gls{MTASK}, a \gls{TOP} system for \gls{IOT} edge devices.
-Finally, it compares how this approach compares to existing approaches for programming \gls{IOT} systems.
+The dissertation shows several techniques for creating \glspl{EDSL} in \cref{prt:dsl}.
+Then it shows a tool, \gls{MTASK}, a \gls{TOP} system for \gls{IOT} edge devices in \cref{prt:top}.
+Finally, in \cref{prt:tvt} it compares how this approach compares to existing approaches for programming \gls{IOT} systems.
-\subsection{Tool craft}
+\subsection{\nameref{prt:dsl}}
\Cref{prt:dsl} presents some tool crafting techniques that are useful for creating \gls{TOP} languages for \gls{IOT} edge devices.
It presents two novel techniques for embedding \glspl{DSL} in \gls{FP} languages.
I show how to automatically generate the required boilerplate for shallowly embedded \glspl{DSL} in order to make data types from the host language first-class citizens in the \gls{DSL}.
The scaffolding is generated using template metaprogramming and quasiquotation is used to alleviate the programmer from the syntax burden and support pattern matching.
-\subsection{Tools}
+\todo[inline]{Paar zinnen over het nut van deze tool crafts: het maakt het voor DSL-developpers in het algemeen makkelijker om uitbreidbare DSLs te maken.}
+
+\subsection{\nameref{prt:top}}
General-purpose \gls{TOP} systems cannot run on edge devices due to their significant hardware requirements.
However, with the right techniques, \glspl{DSL} can be created that can be executed on edge devices while maintaining the high abstraction level.
By embedding domain-specific knowledge into the language and execution platform, and leaving out general-purpose functionality, \gls{TOP} languages can be made suitable for edge devices.
Using only three simple functions, devices are connected to \gls{ITASK} servers, \gls{MTASK} tasks are integrated in \gls{ITASK}, and \gls{ITASK} \glspl{SDS} accessed from within \gls{MTASK} tasks.
Its design, integration with \gls{ITASK}, implementation, and green computing facilities are shown.
-\subsection{Comparison}
+\todo[inline]{Paar zinnen over het nut}
+
+\subsection{\nameref{prt:tvt}}
Using tierless programming, many issues that arise with tiered programming are mitigated.
This has already been observed in web applications.
The \gls{MTASK} system show that it is possible to program edge devices of a \gls{IOT} systems using \gls{TOP}.
& \CIRCLE{}\tnote{3}\\
Simple type system & \CIRCLE{} & \CIRCLE{} & \Circle{}
& \CIRCLE{} & \CIRCLE{} & \Circle{}
- & \RIGHTcircle{}\tnote{4}\\
+ & \textcolor{gray}{\CIRCLE{}}\tnote{4}\\
Little boilerplate & \CIRCLE{} & \CIRCLE{} & \Circle{}
& \CIRCLE{} & \CIRCLE{} & \Circle{}
- & \RIGHTcircle{}\tnote{4}\\
+ & \textcolor{gray}{\CIRCLE{}}\tnote{4}\\
\bottomrule
\end{tabular}
\begin{tablenotes}
\usepackage{csquotes}
-\usepackage[natbib,backref,backend=biber,style=authoryear-comp,useprefix=true,uniquelist=false,uniquename=false,giveninits=true,dashed=false,date=year,maxcitenames=2,maxbibnames=99,minnames=1]{biblatex}
+\usepackage[natbib,
+ backref,
+ backend=biber,
+ style=authoryear-comp,
+ useprefix=true,
+ uniquelist=false,
+ uniquename=false,
+ giveninits=true,
+ dashed=false,
+ date=year,
+ maxcitenames=2,
+ maxbibnames=99,
+ minnames=1]{biblatex}
\DeclareSortingNamekeyTemplate{
\keypart{
\namepart{family}
\ifSubfilesClassLoaded{%
\backmatter%
- \bibliography{../bib/other,../bib/self,../bib/tiot}
+ \renewbibmacro*{begentry}{\midsentence}
+ \printbibliography%
\begingroup%
\let\cleardoublepage\clearpage
\printglossary[style=mcolindex]%
\phantomsection{}%
\label{chp:bibliography}
\addcontentsline{toc}{chapter}{Bibliography}
-%\bibliography{bib/other,bib/self,bib/tiot}
\renewbibmacro*{begentry}{\midsentence}
\printbibliography%
\section{Finale}
Traditionally, the \gls{IOT} has been programmed using layered, or tiered, architectures.
Every layer has its own software and hardware characteristics, resulting in semantic friction.
+It is hard to orchestrate the smooth cooperation of the individual components, especially during maintenance of the entire \gls{IOT} application.
\Gls{TOP} is a declarative programming paradigm designed to describe multi-tiered interactive systems from a single source.
+Such a tierless system prevents the orchestration problems of the tiered approach.
However, it is not straightforward to run \gls{TOP} systems on resource-constrained devices such as edge devices.
+The type system of the host language checks the \gls{ITASK} and \gls{MTASK} components as well as their interaction.
The \gls{MTASK} system bridges this gap by providing a \gls{TOP} programming language for edge devices.
It is a full-fledged \gls{TOP} language hosted in a tiny \gls{FP} language.
Manual interleaving of imperative code can be automated to certain extents.
Solutions often require an \gls{RTOS}, have a high memory requirement, do not support local variables, no thread-safe shared memory, no composition or no events as described in \cref{tbl:multithreadingcompare}.
This table extends a comparison table with various solutions to multitasking to \gls{MTASK} in the relevant categories.
-%\todo[inline]{Uitleg over de talen geven}
\begin{table}
\begin{threeparttable}
FlowTask & 2011 & \CIRCLE{} & \CIRCLE{} & \Circle{} & \Circle{} & \Circle{} & \Circle{}\\
Ocram & 2013 & \CIRCLE{} & \CIRCLE{} & \Circle{} & \CIRCLE{} & \Circle{} & \Circle{}\\
C\'eu & 2013 & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{}\\
- \gls{MTASK} & 2022 & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \LEFTcircle{}\tnote{1} & \LEFTcircle{}\tnote{2}\\
+ \gls{MTASK} & 2022 & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{} & \CIRCLE{}\tnote{1} & \CIRCLE{}\tnote{2}\\
\bottomrule
\end{tabular}
\endgroup
\subsection{Security}
The \gls{IOT} has reached the news concerningly many times regarding the lack of security \citep{alhirabi_security_2021}.
The fact that the devices are embedded in the fabric, are hard to reach and thus to update, and can only run limited cryptographic algorithms due to their constrained resources makes security difficult.
-The security of \gls{MTASK} and the used protocols are deliberately overlooked at the moment
+The security of \gls{MTASK} and the used protocols are deliberately overlooked at the moment.
The \gls{MTASK} language and \gls{RTS} are modular.
For example, the communication channels are communication method agnostic and operate through a simple duplex channel interface.
It should therefore be fairly easy to apply standard security measures to them by replacing communication methods and applying off-the-shelve authentication and encryption to the protocol.
These blocks are marked as such, because in the case of a reset of the system, the work must be done again.
Examples of such blocks are \gls{I2C} transmissions or calculations that rely on recent sensor data.
In \gls{MTASK}, all work expressed by tasks is already split up in atomic pieces of work, i.e.\ the work is a side effect of rewriting.
-Furthermore, creating checkpoints should be fairly straightforward as \gls{MTASK} tasks do not rely on any global state---all information required to execute a task is stored in the task tree.
+Furthermore, creating checkpoints is fairly straightforward as \gls{MTASK} tasks do not rely on any global state---all information required to execute a task is stored in the task tree.
It is interesting to see what \gls{TOP} abstraction are useful for intermittent computing and what solutions are required to make this work.
Mesh networks allow for communication not only to and fro the device and server but also between devices.
For example, it is possible to run tasks or share data with \glspl{SDS} on different machines.
It is interesting to investigate how this networking technique can be utilised in \gls{MTASK}.
-Finally, \glspl{FPGA} have been becoming cheaper and faster recently, allowing for purely functional code to be translated to \glspl{FPGA} code efficiently \citep{baaij_digital_2015}.
+\Glspl{FPGA} have been becoming cheaper and faster recently, allowing for purely functional code to be translated to \glspl{FPGA} code efficiently \citep{baaij_digital_2015}.
It would be interesting to see how and whether (parts of) \gls{TOP} programs or the functionality of the \gls{MTASK} \gls{OS} could be translated to \gls{FPGA} specifications.
\subsection{Formal semantics}
Furthermore, it is unclear whether all derived combinators from \gls{ITASK} can be expressed in terms of \gls{MTASK} combinators.
\Citet{van_der_aalst_workflow_2003} defines a benchmark set of workflow patterns.
It is interesting to see which patterns can be implemented with \gls{MTASK}, and what additional combinators are needed.
-Moreover, editors are a crucial part of \gls{TOP}.
+
+Editors are a crucial part of \gls{TOP}.
In \gls{MTASK}, sensors can be seen as read-only shared editors that are updated by the system.
It is interesting to investigate how actual interactive editors would fit in \gls{MTASK}.
For example, many smartwatches contain touch sensitive screens that could be used to interact with the user in this way.
\subsection{Using 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 quantitatively and qualitatively compared to the original application that was developed using a traditional \gls{IOT} stack \citep{lubbers_tiered_2020}.
-This research was later extended to include a four-way comparison: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK}, and \gls{MTASK} \citep{lubbers_could_2023}.
+This research was later extended to include a four-way comparison: \gls{PYTHON}, \gls{MICROPYTHON}, \gls{ITASK}, and \gls{MTASK} \citep{lubbers_could_2023} (see \cref{chp:smart_campus}).
Currently, power efficiency behaviour of traditional versus \gls{TOP} \gls{IOT} stacks is being compared as well adding a FreeRTOS, and an Elixir implementation to the mix as well.
\input{subfilepostamble}
A processor like the ESP8266 driving the \gls{WEMOS} D1 mini loses the content of its \gls{RAM} in deep sleep mode.
As a result, after waking up, the program itself is preserved, since it is stored in flash memory, but the program state is lost.
When there is a program state to be preserved, we must either store it elsewhere, limit us to light sleep, or use a microcontroller that keeps the \gls{RAM} intact during deep sleep.
+\todo[inline]{Na de voorgaande hoofdstukken kun je dit makkelijk expliciet maken voor mtask.
+For mTasks this implies that the mTask OS is preserved during deep sleep, but all shipped tasks and their states will be lost.}
For edge devices executing a single task, explicit sleeping to save energy can be achieved without too much hassle.
This becomes much more challenging as soon as multiple independent tasks run on the same device.
Reading \glspl{SDS} and measuring fast sensors such as sound or light aim for a rewrite every \qty{100}{\ms}.
Medium slow sensors such as gesture sensors are expected to rewrite every \qty{1000}{\ms}.
Slow sensors such as temperature or air quality have an upper bound of \qty{2000}{\ms}.
+In \cref{sec:tweak_rewrite} we show how the programmer can tweak these rewrite rates to match specific needs.
\begin{table}
\centering
In case of the \cleaninline{rpeat} task, the default refresh rate is $\rewriterate{0}{0}$ so the task immediately refreshes and starts the task again.
\subsubsection{Delay combinators}
-Upon installation, a \cleaninline{delay} task is stored as a \cleaninline{waitUntil} task tree containing the time of installation added to the specified time to wait.
+Upon installation, a \cleaninline{delay} task is stored as a \cleaninline{waitUntil} task, containing the time of installation added to the specified time to wait.
Execution wise, it waits until the current time exceeds the time is greater than the argument time.
\subsubsection{Other tasks}
\end{tabular}
\end{table}
-\subsection{Tweaking rewrite rates}
+\subsection{Tweaking rewrite rates}\label{sec:tweak_rewrite}
A tailor-made \gls{ADT} (see \cref{lst:interval}) is used to tweak the timing intervals.
The value is determined at runtime, but the constructor is known at compile time.
During compilation, the constructor of the \gls{ADT} is checked and code is generated accordingly.
On systems that lose the content of their \gls{RAM} it is not possible to go to deep sleep mode.
\section{Interrupts}\label{lst:interrupts}
+\todo[inline]{
+Ik zou hier een klein algemeen verhaal over interrupts schrijven om te zorgen dat de lezer weet waarom dit de moeite van het lezen waard is. B.v.
+An interrupt is a request for the processor to interrupt the currently exected code or its sleep, to handle the event. It is typically much more energy efficient and accurate when a sensor interrupts the processor to notify that something interresting is happening than when the processor repeatedly checks that sensor's state.
+}
Most microcontrollers have built-in support for processor interrupts.
These interrupts are hard-wired signals that interrupts the normal flow of the program in order to execute a small piece of code, the \gls{ISR}.
While the \glspl{ISR} look like regular functions, they do come with some limitations.
Those interrupts offer a more elegant and energy efficient implementation of watching an input than polling this input.
The actual reduction of the energy is of course highly dependent on the number and nature of the task shipped to the edge device.
-Our examples show a reduction in energy consumption of two orders of magnitude.
+Our examples show a reduction in energy consumption of two orders of magnitude (see \citep{crooijmans_reducing_2022}).
Those reductions are a necessity for edge devices running of battery power.
Given the exploding number of \gls{IOT} edge devices, such savings are also mandatory for other devices to limit the total power consumption of the \gls{IOT}.
\subsection{Shared data sources}\label{lst:imp_sds}
The compilation scheme for \gls{SDS} definitions is a trivial extension to $\mathcal{F}$.
-While there is no code generated, metadata is added to the compiler state identifying the \gls{SDS}, this is seen later in \cref{lst:comp_sds}.
+While there is no code generated in the definition, the byte code compiler is storing all \gls{SDS} data in the \cleaninline{bcs_sdses} field in the compilation state.
+Regular \glspl{SDS} are stored as \cleaninline{Right String255} values.
+The \glspl{SDS} are typed as functions in the host language, so an argument for this function must be created that represents the \gls{SDS} on evaluation.
+For this, an \cleaninline{BCInterpret} is created that emits this identifier.
+When passing it to the function, the initial value of the \gls{SDS} is returned.
+In the case of a local \gls{SDS}, this initial value is stored as a byte code encoded value in the state and the compiler continues with the rest of the program.
\begin{align*}
\cschemeF{\text{\cleaninline{sds}}~x=i~\text{\cleaninline{In}}~m} & =
{} & \mathbin{\phantom{=}} \text{\cleaninline{BCMkTask}} (\text{\cleaninline{BCSdsSet}} s);\\
\end{align*}
-While there is no code generated in the definition, the byte code compiler is storing all \gls{SDS} data in the \cleaninline{bcs_sdses} field in the compilation state.
-Regular \glspl{SDS} are stored as \cleaninline{Right String255} values.
-The \glspl{SDS} are typed as functions in the host language, so an argument for this function must be created that represents the \gls{SDS} on evaluation.
-For this, an \cleaninline{BCInterpret} is created that emits this identifier.
-When passing it to the function, the initial value of the \gls{SDS} is returned.
-In the case of a local \gls{SDS}, this initial value is stored as a byte code encoded value in the state and the compiler continues with the rest of the program.
-
\Cref{lst:comp_sds} shows the implementation of the \cleaninline{sds} type class.
First, the initial \gls{SDS} value is extracted from the expression by bootstrapping the fixed point with a dummy value.
This is safe because the expression on the right-hand side of the \cleaninline{In} is never evaluated.
\caption{Memory layout in the \gls{MTASK} \gls{RTS}.}\label{fig:memory_layout}
\end{figure}
-A task is stored below the stack and its complete state is a \gls{CLEAN} record contain most importantly the task id, a pointer to the task tree in the heap (null if not initialised yet), the current task value, the configuration of \glspl{SDS}, the configuration of peripherals, the byte code and some scheduling information.
+A task is stored below the stack and it consists of the task id, a pointer to the task tree in the heap (null if not initialised yet), the current task value, the configuration of \glspl{SDS}, the configuration of peripherals, the byte code and some scheduling information.
In memory, task data grows from the bottom up and the interpreter stack is located directly on top of it growing in the same direction.
As a consequence, the stack moves when a new task is received.
This is possible because there is no sharing or cycles in task trees and nodes contain pointers to their parent.
-\section{C code generation}\label{sec:ccodegen}
+\section{C code generation for communication}\label{sec:ccodegen}
All communication between the \gls{ITASK} server and the \gls{MTASK} server is type parametrised.
From the structural representation of the type, a \gls{CLEAN} parser and printer is constructed using generic programming.
Furthermore, a \ccpp{} parser and printer is generated for use on the \gls{MTASK} device.
\subsection{Client}
The \gls{RTS} of the \gls{MTASK} system runs on resource-constrained microcontrollers and is implemented in portable \ccpp{}.
In order to achieve more interoperation safety, the communication between the server and the client is automated, i.e.\ the serialisation and deserialisation code in the \gls{RTS} is generated.
+\todo[inline]{Dit naar voren halen naar 7.4.0?}
The technique used for this is very similar to the technique shown in \cref{chp:first-class_datatypes}.
However, instead of using template metaprogramming, a feature \gls{CLEAN} lacks, generic programming is used also as a two-stage rocket.
In contrast to many other generic programming systems, \gls{CLEAN} allows for access to much of the metadata of the compiler.
repositories / phd-thesis.git / commitdiff