From d11a7941da4024ec8ff9ef6afaebb6eb9d2c6ed4 Mon Sep 17 00:00:00 2001 From: Mart Lubbers Date: Sun, 4 Jun 2017 11:43:06 +0200 Subject: [PATCH] update future research and start with mTask extensions --- conclusion.tex | 90 ++++++++++++++++++++++++++++++++-------------- glossaries.tex | 3 ++ methods.mtask.tex | 16 ++++----- results.itasks.tex | 8 +++++ results.mtask.tex | 65 ++++++++++++++++++++++----------- thesis.tex | 3 ++ 6 files changed, 131 insertions(+), 54 deletions(-) create mode 100644 results.itasks.tex diff --git a/conclusion.tex b/conclusion.tex index 6ee7e67..de3da6c 100644 --- a/conclusion.tex +++ b/conclusion.tex @@ -24,31 +24,69 @@ the first device that possibly takes over some of the functionality of the 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. diff --git a/glossaries.tex b/glossaries.tex index ad7701a..1e99f7f 100644 --- a/glossaries.tex +++ b/glossaries.tex @@ -30,6 +30,8 @@ \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}}} @@ -51,3 +53,4 @@ \newglossacr{AST} {Abstract Syntax Tree} \newglossacr{GPS} {Global Positioning System} \newglossacr{GLONASS}{Global Navigation Satellite System} +\newglossacr{RWST}{Reader Writer State Transformer Monad} diff --git a/methods.mtask.tex b/methods.mtask.tex index 4a71394..67f4b4e 100644 --- a/methods.mtask.tex +++ b/methods.mtask.tex @@ -92,9 +92,9 @@ class seq v where \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}] @@ -180,7 +180,7 @@ To achieve this in the \gls{EDSL} a \gls{Task} clas are added that work in a 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. @@ -197,10 +197,10 @@ Some example \glspl{mTask} using almost all of the functionality are shown in 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}}] diff --git a/results.itasks.tex b/results.itasks.tex new file mode 100644 index 0000000..4cbc80e --- /dev/null +++ b/results.itasks.tex @@ -0,0 +1,8 @@ +\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} diff --git a/results.mtask.tex b/results.mtask.tex index a498dce..8b0fb20 100644 --- a/results.mtask.tex +++ b/results.mtask.tex @@ -1,25 +1,50 @@ -\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} diff --git a/thesis.tex b/thesis.tex index 26697c2..ceb2fb2 100644 --- a/thesis.tex +++ b/thesis.tex @@ -61,6 +61,9 @@ \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} -- 2.20.1