\section{\acrlong{TOP}}
\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}
\section{\acrlong{EDSL}s}
\glspl{mTask} are expressed in a class based shallowly embedded \gls{EDSL}.
\todo{Small deep embedded dsl}
\todo{Show that class based has the best of both worlds}
+\section{Architecture}
\section{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. 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}, also includes functions for accessing
-the peripherals that not every device might have. The interface headers also
-show which functionality is implemented and which functionality is not
-available. This information is exchanged during the setup of the communication.
+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.
+\todo{Supported devices}
\subsection{Specification}
Devices are stored in a record type and all devices in the system are stored in
-a \gls{SDS} containing all devices.
+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
+ ,taskSpace :: Int // Bytes
+ ,sdsSpace :: Int // Bytes
+ }
+\end{lstlisting}
+\todo{Explain specification, combine task and share space}
+
+\subsection{Communication}
+
+\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}
+%\todo{Handshake, device specification sending, spec.c}
+%\todo{mTaskDevice class interface}
\section{mTasks}
\subsection{\gls{EDSL}}
Shares are used to store the values
Shares all have
-%\subsection{Serial port communication in Clean and iTasks}
-%In the first exploration stage I added duplex serial port communication to
-%iTasks in the same way as TCP is added. To make it work several changes had to
-%be done to the iTasks core to allow backgroundtasks to be added at runtime. The
-%function shown in Listing~\ref{lst:serialtask} results into a task that
-%sends the data added to the output queue through the serial port and adds data
-%received to the input queue for the user to process.
-%
-%\begin{lstlisting}[caption={Serial port communication in iTasks},
-% language=Clean,label={lst:serialtask}]
-%syncSerialChannel :: String TTYSettings (Shared ([String],[String],Bool)) -> Task ()
-%
-%:: ByteSize = BytesizeFive | BytesizeSix | BytesizeSeven | BytesizeEight
-%:: Parity = ParityNone | ...ParityOdd | ParityEven | ParitySpace | ParityMark
-%:: BaudRate = ... | B9600 | B19200 | ...
-%:: TTYSettings = {
-% baudrate :: BaudRate,
-% bytesize :: ByteSize,
-% parity :: Parity,
-% stop2bits :: Bool,
-% xonxoff :: Bool}
-%\end{lstlisting}
-%
-%\subsection{mTasks}
-%The core of the project revolves around the embedded domain specific language
-%(EDSL) called mTask designed by Pieter Koopman. mTasks is used to use the task
-%oriented programming on microcontrollers in a type-safe environment. Originally
-%mTasks are compiled to c code that could be compiled for arduino compatible
-%devices. Such generated code will be flashed to the program memory once. In
-%short, the original mTask system is comparable to an entire iTasks sytem
-%including the engine.
-%
-%For this project the imperative language constructs of the mTask DSL are used.
-%Listing~\ref{lst:mtask} shows some of these class base DSL components for
-%things like arithmetics, sequencing, conditionals, shared data sources and
-%interaction with the user LEDs. Together with some helper functions code
-%programmed in this DSL can be compiled to bytecode and sent to a device.
-%
-%\begin{lstlisting}[language=Clean,label={lst:mtask},
-% caption={Parts of the mTask DSL}]
-%:: Upd = Upd
-%:: Expr = Expr
-%:: Stmt = Stmt
-%:: UserLED = LED1 | LED2 | LED3
-%
-%:: Main a = {main :: a}
-%
-%class arith v where
-% lit :: t -> v t Expr | ...
-% (+.) infixl 6 :: (v t p) (v t q) -> v t Expr | ...
-%class IF v where
-% IF :: (v Bool p) (v t q) (v s r) -> v () Stmt | isExpr p
-%class sds v where
-% sds :: ((v t Upd)->In t (Main (v c s))) -> (Main (v c s)) | ...
-% pub :: (v t Upd) -> v t Expr | ...
-%class seq v where
-% (:.) infixr 0 :: (v t p) (v u q) -> v u Stmt | ...
-%class assign v where
-% (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ...
-%class noOp v where noOp :: v t p
-%class userLed v where
-% ledOn :: UserLED -> (v () Stmt)
-% ledOff :: UserLED -> (v () Stmt)
-%\end{lstlisting}
-%
-%\subsection{iTasks}
-%In iTasks several tasks have been devised to handle the communication. Moreover
-%the tasks will synchronize the shared data sources in the mTask domain with
-%real SDSs in the iTasks domain allowing for communication between mTasks and
-%iTasks tasks. To not clutter the communication channels the SDSs are not
-%synchronized on every change on the device. When a share changes on the server
-%his new value will be pushed to the device immediately. When a share is updated
-%on the client it must be explicitly published using. This approach has been
-%taken because some shares might be only used internally and therefore would
-%clutter the communication channels that could be low-bandwidth.
-%
-%
-%\subsection{Devices}
-%For the devices an engine has been built that can receive mTasks and SDSs and
-%execute them accordingly. To add a new device to the list the programmer just
-%has to implement a relatively small interface. All the other functionality is
-%using standard C or the interface. This interface is listed in~%
-%\ref{lst:interface} and includes reading and writing data, controlling the
-%peripherals and some auxiliary functions.
-%
-%\begin{lstlisting}[language=c,caption={Device interface},label={lst:interface}]
-%uint8_t read_byte(void);
-%void write_byte(uint8_t b);
-%
-%void write_dpin(uint8_t i, bool b);
-%bool read_dpin(uint8_t i);
-%
-%void write_apin(uint8_t i, uint8_t a);
-%uint8_t read_apin(uint8_t i);
-%
-%long millis(void);
-%bool input_available(void);
-%void delay(long ms);
-%
-%void setup(void);
-%void debug(char *fmt, ...);
-%void pdie(char *s);
-%void die(char *fmt, ...);
-%\end{lstlisting}
-%
-%mTasks run either at a fixed interval or are one-shot which is added to the
-%message. The entire protocol specification can be found in the code that is
-%available. When an mTask is one-shot it will only be executed once and then
-%removed. This can be useful for user related tasks such as shutting down blinds
-%or turning on lights for an indefinite time. mTasks that run at a fixed
-%interval time can be used to monitor sensors or to periodically communicate
-%with peripherals like LCD screens.
-%
-%There are many things to be improved upon in future research. Most likely these
-%points will be touched upon in my Master's thesis research.
-%\begin{itemize}
-% \item Support task combinators and functions.
-%
-% The mTask language already supports the step combinator and it might be
-% fruitful to add for more expressively. Moreover functions would also
-% add a lot. They can be used to share code between tasks to reduce the
-% bytecode size.
-% \item Seamless integration with iTasks.
-%
-% At the moment everything works but is hacked together. I would like to
-% extend this with a more robust system that allows adding devices on the
-% fly and adds functionality to monitor the mTask devices.
-% \item Dynamic mTask/SDS allocation.
-%
-% Currently all client data for mTask and SDS storage is statically
-% allocated. This means that when only a few tasks are used the memory
-% needed is too high. This can be improved upon by only allocating
-% resources for tasks when they are requested and this would allow the
-% system to run on low memory devices like arduino's.
-% \item Extend on SDSs.
-%
-% In the current system the shared data sources used in mTask programs
-% live in a different domain and are synchronized with an iTask
-% counterpart. Programming mTasks could be made more intuitive if you
-% could use standard SDSs from iTasks. Moreover, at the moment only
-% integer and boolean shares are allowed. This really should be extended
-% to at least strings.
-% \item Slicing tasks.
-%
-% Every mTask runs in its entirety and to not run into race and
-% scheduling problems loops are not allowed in the mTasks. An improvement
-% to this could be multithreading the tasks by giving them slices of
-% computation and pausing them every slice. In this way loops could be
-% allowed without blocking the entire system. It does require more memory
-% however.
-% \item Run tasks when an interrupt fires.
-%
-% Tasks can be scheduled either one-shot or at an interval. It might be
-% useful to tie mTasks to hardware interrupts to increase responsiveness
-% and possibly battery life. These interrupts do not need to be hardware
-% based. A usecase might be to run a task when some other task is
-% yielding a value (see task combinators) or to run a task when a shared
-% data source is received from the server.
-%\end{itemize}
repositories / msc-thesis1617.git / blobdiff