From: Mart Lubbers Date: Tue, 2 May 2017 13:06:17 +0000 (+0200) Subject: add part about deep embedding X-Git-Tag: hand-in~135 X-Git-Url: https://git.martlubbers.net/?a=commitdiff_plain;h=d0c05e34c230ff8292466e58709d1f45feb05919;p=msc-thesis1617.git add part about deep embedding --- diff --git a/methods.arch.tex b/methods.arch.tex new file mode 100644 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 --- 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 --- 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 --- 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}