X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=methods.tex;h=1cf3b68de54ff97a5d7fb6e1dc728295dbd0f0f8;hb=0bc7120dbe8ab9e0262b1f7cf98dacaf1d6a14ac;hp=674a24fd145c35b8c4a17d4398399732f97fefd6;hpb=e22d3df9367912afcb12b638ad5ae8b66932d986;p=msc-thesis1617.git diff --git a/methods.tex b/methods.tex index 674a24f..1cf3b68 100644 --- a/methods.tex +++ b/methods.tex @@ -1,30 +1,77 @@ \section{\acrlong{TOP}} +\subsection{\gls{iTasks}} \gls{TOP} is a recent new programming paradigm implemented as -\gls{iTasks}~\cite{achten_introduction_2015} in -the pure lazy functional language \gls{Clean} +\gls{iTasks}\cite{achten_introduction_2015} in the pure lazy functional +language \gls{Clean}\cite{brus_cleanlanguage_1987}. \gls{iTasks} is a +\gls{EDSL} to model workflow tasks in the broadest sense. A \CI{Task} is just +a function that, given some state, returns the observable value of the +\CI{TaskValue}. A simple example is shown in Listing~\ref{lst:taskex} +accompanied with Figure~\ref{fig:taskex1},~\ref{fig:taskex2} and~% +\ref{fig:taskex3}. -\todo{Main terms} -The lazy functional programming language based on graph rewriting -\gls{Clean}~\cite{brus_cleanlanguage_1987} +\begin{lstlisting}[language=Clean,label={lst:taskex},% + caption={An example \gls{Task} for entering a name}] +:: Name = { firstname :: String + , lastname :: String + } + +derive class iTask Name + +enterInformation :: String [EnterOption m] -> (Task m) | iTask m + +enterName :: Task Name +enterName = enterInformation "Enter your name" [] +\end{lstlisting} + +\begin{figure}[H] + \begin{subfigure}{.25\textwidth} + \centering + \includegraphics[width=.9\linewidth]{taskex1} + \caption{Initial interface}\label{fig:taskex1} + \end{subfigure} + \begin{subfigure}{.25\textwidth} + \centering + \includegraphics[width=.9\linewidth]{taskex2} + \caption{Incomplete entrance}\label{fig:taskex2} + \end{subfigure} + \begin{subfigure}{.25\textwidth} + \centering + \includegraphics[width=.9\linewidth]{taskex3} + \caption{Complete entry}\label{fig:taskex3} + \end{subfigure} + \caption{Example of a generated user interface} +\end{figure} + +\subsection{Combinators} \section{\acrlong{EDSL}s} +\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}. \todo{Small shallow embedded dsl intro} \todo{Small deep embedded dsl} \todo{Show that class based has the best of both worlds} -\section{Devices} +\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\todo{handshake}. 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. +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 @@ -38,11 +85,10 @@ 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 - ,taskSpace :: Int // Bytes - ,sdsSpace :: Int // Bytes + {haveLed :: Bool + ,haveAio :: Bool + ,haveDio :: Bool + ,bytesMemory :: Int } \end{lstlisting} \todo{Explain specification, combine task and share space} @@ -51,6 +97,68 @@ exact specification is listed in Listing~\ref{lst:devicespec} \section{mTasks} \subsection{\gls{EDSL}} +The \gls{mTask}-\gls{EDSL} contains several classes that need to be implemented +by a type for it to be an \gls{mTask}. For numeric and boolean arithmetic the +classes \texttt{arith} and \texttt{boolExpr} are available and listed in a +shortened version in Listing~\ref{lst:arithbool}. All classes are to be +implemented by types of kind \texttt{*->*->*} a type \texttt{v t p}, +respectively a view with a type and the role. +\texttt{lit} lifts a constant to the \gls{mTask} domain. For a type to be a +valid \gls{mTask} type it needs to implement the \texttt{mTaskType} class. The +binary operators work as expected. + +\begin{lstlisting}[language=Clean,label={lst:arithbool}, + caption={Basic classes for expressions}] +class mTaskType a | toByteCode, fromByteCode, iTask, TC a + +class arith v where + lit :: t -> v t Expr | mTaskType t + (+.) infixl 6 :: (v t p) (v t q) -> v t Expr | type, +, zero t & isExpr p & isExpr q + ... +class boolExpr v where + (&.) infixr 3 :: (v Bool p) (v Bool q) -> v Bool Expr | isExpr p & isExpr q + Not :: (v Bool p) -> v Bool Expr | isExpr p + ... + (==.) infix 4 :: (v a p) (v a q) -> v Bool Expr | ==, toCode a & isExpr p & isExpr q +\end{lstlisting} + + +\subsection{Tasks} \subsection{Shares} +Shares can live on multiple clients at the same time. For every share created +for an \gls{mTask} a real \gls{SDS} is created that mirrors the value on the +client. All shares currently in use are stored in a system-wide \gls{SDS} in +such a way that the actual share can be retrieved at any moment. All shares +have a unique numeric identifier and an initial value. + +\begin{lstlisting}[language=Clean,label={lst:sharespec}, caption={\acrlong{SDS}}] +:: BCValue = E.e: BCValue e & mTaskType e +:: MTaskShareType = MTaskWithShare String | MTaskLens String +:: MTaskShare = + {withTask :: [String] + ,withDevice :: [String] + ,identifier :: Int + ,realShare :: MTaskShareType + ,value :: BCValue + } + +sdsStore :: Shared [MTaskShare] +\end{lstlisting} +\todo{Do something with the sharetype} + +\subsection{Communication} +%\todo{Handshake, device specification sending, spec.c} +%\todo{mTaskDevice class interface} + +\section{mTasks} +\subsection{\gls{EDSL}} +\todo{Show the classes} + +\subsection{Shares} +\todo{Show the types and why} + +Shares are used to store the values + +Shares all have