add part about deep embedding

diff --git a/methods.arch.tex b/methods.arch.tex
new file mode 100644 (file)
index 0000000..3cf1487
--- /dev/null
+++ b/methods.arch.tex
@@ -0,0 +1,42 @@
+\section{Architecture}
+\subsection{Devices}
+The client code for the devices is compiled from one codebase. For a device to
+be eligible for \glspl{mTask} it must be able to compile the shared codebase
+and implement (part of) the device specific interface. The shared codebase only
+uses standard \gls{C} and no special libraries or tricks are used. Therefore
+the code is compilable for almost any device or system. Note that it is not
+needed to implement a full interface. The full interface, listed in
+Appendix~\label{app:device-interface}\todo{update interface listing}, also
+includes functions for accessing the peripherals that not every device might
+have. Devices can choose what to implement by setting the correct macros in the
+top of the file. When a server connects to a client the specifications are
+communicated.
+
+The current list of supported and tested devices is as follows:
+\begin{itemize}
+       \item $^*$\texttt{NIX} systems such as Linux
+       \item STM32 like development boards supported by \texttt{ChibiOS}.
+       \item \emph{Arduino} compatible microcontrollers
+\end{itemize}
+
+\subsection{Specification}
+Devices are stored in a record type and all devices in the system are stored in
+a \gls{SDS} containing all devices. From the macro settings in the interface
+file a profile is created for the device that describes the specification. When
+a connection between the server and a client is established the server will
+send a request for specification. The client will serialize his specs and send
+it to the server so that the server knows what the client is capable of. The
+exact specification is listed in Listing~\ref{lst:devicespec}
+
+\begin{lstlisting}[language=Clean,label={lst:devicespec},
+       caption={Device specification for \glspl{mTask}}]
+:: MTaskDeviceSpec =
+       {haveLed     :: Bool
+       ,haveAio     :: Bool
+       ,haveDio     :: Bool
+       ,bytesMemory :: Int
+       }
+\end{lstlisting}
+\todo{Explain specification, combine task and share space}
+
+\subsection{Communication}

diff --git a/methods.dsl.tex b/methods.dsl.tex
index 50a5138..639eec4 100644 (file)
--- a/methods.dsl.tex
+++ b/methods.dsl.tex
@@ -1,4 +1,56 @@
 \section{\acrlong{EDSL}s}
+There are several techniques available for creating \glspl{EDSL}. Each of
+them have their own advantages and disadvantages such as extendability,
+typedness and view support. In the following subsections each of the main
+techniques are briefly explained.
+
+\subsection{Deep embedding}
+A deep \gls{EDSL} means that the language is represented as an \gls{ADT}. Views
+are functions that transform something to the datatype or the other way around.
+As an example we have the simple arithmetic \gls{EDSL} shown in
+Listing~\ref{lst:exdeep}. Deep embedding has the advantage that it is very
+simple to build and the views are easy to make and add. However, there are also
+a few downsides.
+
+\begin{lstlisting}[language=Clean,label={lst:exdeep},caption={A minimal deep
+\gls{EDSL}}]
+:: DSL
+       = LitI Int
+       | LitB Bool
+       | Var String
+       | Plus DSL DSL
+       | Minus DSL DSL
+       | And DSL DSL
+       | Eq DSL
+\end{lstlisting}
+
+The expressions created with this language are not type-safe. In the given
+language it is possible an expression such as \CI{Plus (LitI 4) (LitB True)}
+which to add a boolean to an integer. Evermore so, extending the \gls{ADT} is
+easy and convenient but extending the views accordingly is tedious and has to
+be done individually for all views.
+
+The first downside of the type of \gls{EDSL} can be overcome by using
+\glspl{GADT}. Listing~\ref{lst:exdeepgadt} shows the same language, but
+type-safe with a \gls{GADT}\footnote{Note that \glspl{GADT} are not supported
+in \gls{Clean}. They can be simulated using bimaps}\todo{cite}. Unfortunately
+the lack of extendability stays a problem.
+
+\begin{lstlisting}[language=Clean,label={lst:exdeep},%
+       caption={A minimal deep \gls{EDSL}}]
+:: DSL a
+       = LitI Int                     -> DSL Int
+       | LitB Bool                    -> DSL Bool
+       | Var String                   -> DSL Int
+       | Plus   (DSL Int) (DSL Int)   -> DSL Int
+       | Minus  (DSL Int) (DSL Int)   -> DSL Int
+       | And    (DSL Bool) (DSL Bool) -> DSL Bool
+       | E.e: Eq (DSL e) (DSL e)       -> DSL Bool   & == e
+\end{lstlisting}
+
+\subsection{Shallow embedding}
+
+\subsection{Class based shallow embedding}
 \todo{while iTasks is also a DSL\ldots}
 \glspl{mTask} are expressed in a class based shallowly embedded \gls{EDSL}.
 There are two main types of \glspl{EDSL}.

diff --git a/methods.tex b/methods.tex
index 7850c82..e25809c 100644 (file)
--- a/methods.tex
+++ b/methods.tex
@@ -2,48 +2,7 @@
 
 \input{methods.dsl.tex}
 
-\section{Architecture}
-\subsection{Devices}
-The client code for the devices is compiled from one codebase. For a device to
-be eligible for \glspl{mTask} it must be able to compile the shared codebase
-and implement (part of) the device specific interface. The shared codebase only
-uses standard \gls{C} and no special libraries or tricks are used. Therefore
-the code is compilable for almost any device or system. Note that it is not
-needed to implement a full interface. The full interface, listed in
-Appendix~\label{app:device-interface}\todo{update interface listing}, also
-includes functions for accessing the peripherals that not every device might
-have. Devices can choose what to implement by setting the correct macros in the
-top of the file. When a server connects to a client the specifications are
-communicated.
-
-The current list of supported and tested devices is as follows:
-\begin{itemize}
-       \item $^*$\texttt{NIX} systems such as Linux
-       \item STM32 like development boards supported by \texttt{ChibiOS}.
-       \item \emph{Arduino} compatible microcontrollers
-\end{itemize}
-
-\subsection{Specification}
-Devices are stored in a record type and all devices in the system are stored in
-a \gls{SDS} containing all devices. From the macro settings in the interface
-file a profile is created for the device that describes the specification. When
-a connection between the server and a client is established the server will
-send a request for specification. The client will serialize his specs and send
-it to the server so that the server knows what the client is capable of. The
-exact specification is listed in Listing~\ref{lst:devicespec}
-
-\begin{lstlisting}[language=Clean,label={lst:devicespec},
-       caption={Device specification for \glspl{mTask}}]
-:: MTaskDeviceSpec =
-       {haveLed     :: Bool
-       ,haveAio     :: Bool
-       ,haveDio     :: Bool
-       ,bytesMemory :: Int
-       }
-\end{lstlisting}
-\todo{Explain specification, combine task and share space}
-
-\subsection{Communication}
+\input{methods.arch.tex}
 
 \section{mTasks}
 \subsection{\gls{EDSL}}

diff --git a/thesis.tex b/thesis.tex
index b79e833..caaef4e 100644 (file)
--- a/thesis.tex
+++ b/thesis.tex
@@ -2,6 +2,8 @@
 \usepackage[nonumberlist,acronyms]{glossaries}
 \makeglossaries%
 
+\newacronym{GADT}{GADT}{Generalized Algebraic Datatype}
+\newacronym{ADT}{ADT}{Algebraic Datatype}
 \newacronym{SDS}{SDS}{Shared Data Source}
 \newacronym{IoT}{IoT}{Internet of Things}
 \newacronym{TOP}{TOP}{Task Oriented Programming}