broken device without needing to recompile the code.
\section{Discussion}
+\todo{class based shallow doesn't have multiple backend support}
+\todo{slow client software because of intepretation}
+\todo{What happens if a device dies? Task resending, add to handshake}
+
\section{Future Research}
-Future improvements of the system could be:
-\begin{itemize}
- \item Add an additional simulation view to the \gls{mTask}-\gls{EDSL} that
- simulates the bytecode interpreter and possibly functions as a full
- fledged device, thus handling all communication through the existing
- system.
- \item Add true multitasking to the client software allowing
- \gls{mTask}-\glspl{Task} to run truly parallel. This does require
- separate stacks for each task and therefore increases the system
- requirements of the client software. However, it could be implemented
- as a compile-time option and exchanged during the handshake so that the
- server knows the multithreading capabilities of the client.
- \item Resource analysis during compilation can be useful to determine if an
- \gls{mTask}-\gls{Task} is suitable for a specific device. If the device
- does not contain the correct peripherals such as an \gls{LCD} then the
- \gls{mTask}-\gls{Task} should be rejected and feedback to the user must
- be given. This could also be extended to minimum stack size needed to
- run the task and memory requirements for storing the \gls{Task}.
- \item Implement more \gls{Task} combinators such as the step combinator to
- allow for more fine-grained control flow between
- \gls{mTask}-\glspl{Task}. This could be extended to a similar system
- as in the \gls{C}-code generation view. The \glspl{Task} can launch
- other \glspl{Task} and compose \glspl{Task} of subtasks.
- \item Implement other classes from the \gls{mTask}-\gls{EDSL} such as the
- \CI{mtask} class that allows tasks launching new tasks.
-\end{itemize}
+The system is still crude and a proof of concept. Improvements and extension
+for the system are amply available in several fields of study.
+
+\subsection{Simulation}
+An additional simulation view to the \gls{mTask}-\gls{EDSL} could be added that
+works in the same way as the existing \gls{C}-backed simulation. It simulates
+the bytecode interpretation. Moreover would be possible to let the simulator
+function as real device. Thus handling all communication through the
+existing \gls{SDS}-based systems and behave like a real device. At the moment
+the \emph{POSIX}-client is the reference client and contains debugging code.
+Adding a simulation view to the system allows for easy interactive debugging.
+However, it might not be easy to devise a simulation tool that accurately
+simulates the \gls{mTask} system accurately on some levels. The semantics can
+be simulated but for example timing and peripheral input/output are more
+difficult to simulate properly.
+
+\subsection{Optimization}
+True multitasking could be added to the client software. This allows
+\gls{mTask}-\glspl{Task} to run truly parallel. All \glspl{mTask} get slices
+of execution time and will each have their own interpreter state instead of one
+system-wide one that is reset after am \gls{mTask} finishes. This does require
+separate stacks for each task and therefore increases the system requirements
+of the client software. However, it could be implemented as a compile-time
+option and exchanged during the handshake so that the server knows the
+multithreading capabilities of the client.
+
+\subsection{Resources}
+Resource analysis during compilation can be useful to determine if an
+\gls{mTask}-\gls{Task} is suitable for a specific device. If the device does
+not contain the correct peripherals such as an \gls{LCD} then the
+\gls{mTask}-\gls{Task} should be rejected and feedback to the user must be
+given.
+
+This idea could be extended to the analysis of stack size and possibly
+communication bandwidth. With this functionality ever more reliable fail-over
+systems can be designed. When the system knows more precise bounds it can
+allocate more \glspl{Task} on a device whilst staying within safe memory
+bounds. The resource allocation can be done at runtime within the backend
+itself or a general backend can be devices that can calculate the resources
+needed for a given \gls{mTask}. A specific \gls{mTask} can not have multiple
+views at the same time due to the restrictions of class based shallow
+embedding. It might even be possible to encode the resource allocation in the
+type system itself using forms of dependant types.
+
+\subsection{Functionality}
+More task-combinators already existing in the \gls{iTasks}-system could be added
+to the \gls{mTask}-system to allow for more fine-grained control flow between
+\gls{mTask}-\glspl{Task}. In this way the new system follows the \gls{TOP}
+paradigm even more and makes programming \glspl{mTask} for
+\gls{TOP}-programmers more seamless. Some of the combinators require previously
+mentioned extension such as the parallel combinator. Others might be achieved
+using simple syntactic transformations.
+
+Currently the \gls{C}-view allows tasks to launch other tasks. In the current
+system this type of logic has to take place server side. Adding this
+functionality to the bytecode-view allows greater flexibility, easier
+programming and less communication resources. Adding these semantics requires
+modifications to the client software and extensions to the communication
+protocol since relations between tasks also need to be encoded and
+communicated.
\newglossaryentry{Javascript}{name={\emph{Javascript}},
description={is an imperative programming language designed to run in web
browsers}}
+\newglossaryentry{LED}{name={LED},
+ description={Lighting Emitting Diode}}
\newcommand{\newglossacr}[2]{\newglossaryentry{#1}{name={#1},first={%
\glsentrylong{#1} (\glsentryname{#1})},firstplural={\glsentrylong{#1}%
\glspluralsuffix (\glsentryname{#1}\glspluralsuffix},description={#2}}}
\newglossacr{AST} {Abstract Syntax Tree}
\newglossacr{GPS} {Global Positioning System}
\newglossacr{GLONASS}{Global Navigation Satellite System}
+\newglossacr{RWST}{Reader Writer State Transformer Monad}
\section{Input/Output and class extensions}
Values can be assigned to all expressions that have an \CI{Upd} role. Examples
of such expressions are \glspl{SDS} and \gls{GPIO} pins. Moreover, class
-extensions can be created for specific peripherals such as builtin LEDs. The
-classes facilitating this are shown in Listing~\ref{lst:sdsio}. In this way the
-assignment is the same for every assignable entity.
+extensions can be created for specific peripherals such as builtin \glspl{LED}.
+The classes facilitating this are shown in Listing~\ref{lst:sdsio}. In this way
+the assignment is the same for every assignable entity.
\begin{lstlisting}[%
language=Clean,label={lst:sdsio},caption={Input/Output classes}]
similar fashion as the \texttt{sds} class. This class is listed in
Listing~\ref{lst:taskclass}. \glspl{Task} can have an argument and always have
to specify a delay or waiting time. The type signature of the \CI{mtask} is
-rather arcane and therefore an example is given. The aforementioned Listing
+complex and therefore an example is given. The aforementioned Listing
shows a simple specification containing one task that increments a value
indefinitely every one seconds.
Listing~\ref{lst:exmtask}. The \glspl{mTask} shown in the example do not belong
to a particular view and therefore are of the type \CI{View t r}. The
\CI{blink} \gls{mTask} show the classic \gls{Arduino} \emph{Hello World!}
-application that blinks a certain LED every second. The \CI{thermostat}
-expression will enable a digital pin powering a cooling fan when the analog
-pin representing a temperature sensor is too high. \CI{thermostat`} shows the
-same expression but now using the assignment style \gls{GPIO} technique.
+application that blinks a certain \gls{LED} every second. The \CI{thermostat}
+expression will enable a digital pin powering a cooling fan when the analog pin
+representing a temperature sensor is too high. \CI{thermostat`} shows the same
+expression but now using the assignment style \gls{GPIO} technique.
\begin{lstlisting}[%
language=Clean,label={lst:exmtask},caption={Some example \glspl{mTask}}]
--- /dev/null
+\subsection{Shares}
+\todo{Semantiek van shares, hoe ze in iTasks zijn, hoe typering}
+
+\subsection{Lifting}
+\todo{Lift mTask taken naar echte taken, hoe werkt dat?}
+
+\section{Demo}
+\todo{Wat voorbeeld code}
-\section{mTask}
-\subsection{Extension on the \gls{mTask}-\gls{EDSL}}
Some functionality of the original \gls{mTask}-\gls{EDSL} will not be used in
-this sytem. Conversely, some functionality wanted was not available in the
-original system. Due to the nature of class based shallow embedding this is
-very easy to solve. A type housing the \gls{EDSL} does not have to implement
-all the available classes. Moreover, classes can be added at will without
-interfering with the existing views.
-\todo{Aanpassingen aan de mTask DSL}
-
-\subsection{Semantics}
-\todo{Uitleggen wat het systeem precies doet}
+this extension \gls{EDSL}. Conversely, some functionality needed was not
+available in the existing \gls{EDSL}. Due to the nature of class based shallow
+embedding this obstacle is very easy to solve. A type housing the \gls{EDSL}
+does not have to implement all the available classes. Moreover, classes can be
+added at will without interfering with the existing views.
+
+\section{Bytecode compilation view}
+The \glspl{mTask} are sent to the device in bytecode and are saved in the
+memory of the device. To compile the \gls{EDSL} code to bytecode a \gls{RWST}
+is used. The \gls{RWST} is a state transformer stacked on a \emph{Reader} monad
+and a \emph{Writer} monad. In this case the transformer part is not used.
+However, this can be done to add for example better runtime error handling.
+
+\begin{lstlisting}[language=Clean]
+:: ByteCode a p = BC (RWS () [BC] BCState ())
+:: BCValue = E.e: BCValue e & mTaskType, TC e
+:: BCShare = {
+ sdsi :: Int,
+ sdsval :: BCValue
+ }
+:: BCState = {
+ freshl :: [Int],
+ freshs :: [Int],
+ sdss :: [BCShare]
+ }
+
+class toByteCode a :: a -> String
+class fromByteCode a :: String -> a
+class mTaskType a | toByteCode, fromByteCode, iTask, TC a
-\subsection{Bytecode compilation view}
-\todo{Uitwijden hierop}
+instance toByteCode Int, ... , UserLED, BCValue
+instance fromByteCode Int, ... , UserLED, BCValue
-\section{iTasks}
-\subsection{Shares}
-\todo{Semantiek van shares, hoe ze in iTasks zijn, hoe typering}
+instance arith ByteCode
+...
+instance serial ByteCode
+\end{lstlisting}
-\subsection{Lifting}
-\todo{Lift mTask taken naar echte taken, hoe werkt dat?}
+\section{Bytecode compilation view for \gls{mTask}}
+Compilation to bytecode
+
+\subsection{Backend}
+\todo{Aanpassingen
+aan de mTask DSL}
+
+\section{Semantics}
+
+\todo{Uitleggen wat het systeem precies doet}
-\section{Demo}
-\todo{Wat voorbeeld code}
\chapter{mTask continued}\label{chp:mtaskcont}
\input{results.mtask}
+\chapter{iTasks integration}\label{chp:mtaskcont}
+\input{results.itasks}
+
\chapter{Conclusion \& Discussion}\label{chp:conclusion}
\input{conclusion}
repositories / msc-thesis1617.git / commitdiff