roy's comments: chapter 5

[msc-thesis1617.git] / methods.mtask.tex

diff --git a/methods.mtask.tex b/methods.mtask.tex
index d6fcbb3..3ef01f1 100644 (file)
--- a/methods.mtask.tex
+++ b/methods.mtask.tex
@@ -1,29 +1,29 @@
-The \gls{mTask}-\gls{EDSL} is the basis on which the system is built. The
-\gls{mTask}-\gls{EDSL} was created by Koopman et al.\ to support several views
-such as an \gls{iTasks} simulation and a \gls{C}-code generator. The \gls{EDSL}
-was designed to generate a ready-to-compile \gls{TOP}-like system for
-microcontrollers such as the \gls{Arduino}~\cite{koopman_type-safe_nodate}%
+The \gls{mTask}-\gls{EDSL} is the language used in the system. The
+\gls{mTask}-\gls{EDSL} was created by Koopman et al.\ and supported several
+views such as an \gls{iTasks} simulation and a \gls{C}-code generator. The
+\gls{EDSL} was designed to generate a ready-to-compile \gls{TOP}-like program
+for microcontrollers such as the \gls{Arduino}~\cite{koopman_type-safe_nodate}%

 \cite{plasmeijer_shallow_2016}.
 
 The \gls{mTask}-\gls{EDSL} is a shallowly embedded class based \gls{EDSL} and
 therefore it is very suitable to have a new backend that partly implements the
 classes given. The following sections show the details of the \gls{EDSL} that
 \cite{plasmeijer_shallow_2016}.
 
 The \gls{mTask}-\gls{EDSL} is a shallowly embedded class based \gls{EDSL} and
 therefore it is very suitable to have a new backend that partly implements the
 classes given. The following sections show the details of the \gls{EDSL} that

-are used in this extension. The parts of the \gls{EDSL} that are not used will
+is used in this extension. The parts of the \gls{EDSL} that are not used will

 not be discussed and the details of those parts can be found in the cited
 literature.
 
 A view for the \gls{mTask}-\gls{EDSL} is a type with kind \CI{*->*->*}%
 \footnote{A type with two free type variables.} that implements some of the
 classes given. The types do not have to be present as fields in the higher
 not be discussed and the details of those parts can be found in the cited
 literature.
 
 A view for the \gls{mTask}-\gls{EDSL} is a type with kind \CI{*->*->*}%
 \footnote{A type with two free type variables.} that implements some of the
 classes given. The types do not have to be present as fields in the higher

-kinded view and can, and will most often, be exclusively phantom types. A view
-is of the form \CI{v t r}. The first type variable will be the type of the
-view. The second type variable will be the type of the \gls{EDSL}-expression
-and the third type variable represents the role of the expression. Currently
-the role of the expressions form a hierarchy. The three roles and their
-hierarchy are shown in Listing~\ref{lst:exprhier}. This implies that everything
-is a statement, only a \CI{Upd} and a \CI{Expr} are expressions. The \CI{Upd}
-restriction describes updatable expressions such as \gls{GPIO} pins and
-\glspl{SDS}.
+kinded view and can, and will most often, be exclusively phantom types. Thus,
+views are of the form: \CI{:: v t r = ...}.  The first type variable will be
+the type of the view. The second type variable will be the type of the
+\gls{EDSL}-expression and the third type variable represents the role of the
+expression. Currently the role of the expressions form a hierarchy. The three
+roles and their hierarchy are shown in Listing~\ref{lst:exprhier}. This implies
+that everything is a statement, only a \CI{Upd} and a \CI{Expr} are
+expressions. The \CI{Upd} restriction describes updatable expressions such as
+\gls{GPIO} pins and \glspl{SDS}.

 
 \begin{lstlisting}[%
        label={lst:exprhier},caption={Expression role hierarchy}]
 
 \begin{lstlisting}[%
        label={lst:exprhier},caption={Expression role hierarchy}]


@@ -43,8 +43,8 @@ language constructs also contains the function \CI{lit} that lifts a
 host-language value into the \gls{EDSL} domain. All standard arithmetic
 functions are included in the \gls{EDSL} but are omitted in the example for
 brevity. Moreover, the class restrictions are only shown in the first functions
 host-language value into the \gls{EDSL} domain. All standard arithmetic
 functions are included in the \gls{EDSL} but are omitted in the example for
 brevity. Moreover, the class restrictions are only shown in the first functions

-and omitted in subsequent funcitons. Both the boolean expression and arithmetic
-expression classes are shown in Listing~\ref{lst:arithbool}.
+and are omitted in subsequent functions. Both the boolean expression and
+arithmetic expression classes are shown in Listing~\ref{lst:arithbool}.

 
 \begin{lstlisting}[label={lst:arithbool},
        caption={Basic classes for expressions}]
 
 \begin{lstlisting}[label={lst:arithbool},
        caption={Basic classes for expressions}]


@@ -72,8 +72,9 @@ functional dependency on \CI{s} determines the return type of the statement.
 The listing includes examples of implementations that illustrate this
 dependency.
 
 The listing includes examples of implementations that illustrate this
 dependency.
 

-The sequence operator is very straightforward and its only function is to tie
-the together in sequence.
+The sequence operator is straightforward and its only function is to tie
+two expressions together. The left expression is executed first, followed by
+the right expression.

 
 \begin{lstlisting}[%
        label={lst:control},caption={Control flow operators}]
 
 \begin{lstlisting}[%
        label={lst:control},caption={Control flow operators}]


@@ -93,7 +94,7 @@ class seq v where
 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 built-in
 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 built-in

-\glspl{LED}.  The classes facilitating this are shown in
+\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.
 
 Listing~\ref{lst:sdsio}. In this way the assignment is the same for every
 assignable entity.
 


@@ -122,10 +123,12 @@ class assign v where
 \end{lstlisting}
 
 A way of storing data in \glspl{mTask} is using \glspl{SDS}. \glspl{SDS} serve
 \end{lstlisting}
 
 A way of storing data in \glspl{mTask} is using \glspl{SDS}. \glspl{SDS} serve

-as variables in the \gls{mTask} and maintain their value across executions.
+as variables in \gls{mTask} and maintain their value across executions.
+\glspl{SDS} can be used by multiple \glspl{Task} and can be used to share data.

 The classes associated with \glspl{SDS} are listed in
 Listing~\ref{lst:sdsclass}. The \CI{Main} type is introduced to box an
 The classes associated with \glspl{SDS} are listed in
 Listing~\ref{lst:sdsclass}. The \CI{Main} type is introduced to box an

-\gls{mTask} and make it recognizable by the type system.
+\gls{mTask} and make it recognizable by the type system by separating programs
+and decorations such as \glspl{SDS}.

 
 \begin{lstlisting}[%
        label={lst:sdsclass},caption={\glspl{SDS} in \gls{mTask}}]
 
 \begin{lstlisting}[%
        label={lst:sdsclass},caption={\glspl{SDS} in \gls{mTask}}]


@@ -151,9 +154,10 @@ semantics. This engine expressed in pseudocode is listed as
 Algorithm~\ref{lst:engine}. All the \glspl{Task} are inspected on their waiting
 time. When the waiting time has not passed; the delta is subtracted and the
 \gls{Task} gets pushed to the end of the queue. When the waiting has surpassed
 Algorithm~\ref{lst:engine}. All the \glspl{Task} are inspected on their waiting
 time. When the waiting time has not passed; the delta is subtracted and the
 \gls{Task} gets pushed to the end of the queue. When the waiting has surpassed

-they are executed. When an \gls{mTask} wants to queue another \gls{mTask} it
+they are executed. When an \gls{mTask} opts to queue another \gls{mTask} it

 can just append it to the queue.
 
 can just append it to the queue.
 

+~\\

 \begin{algorithm}[H]
        \KwData{\textbf{queue} queue, \textbf{time} $t, t_p$}
 
 \begin{algorithm}[H]
        \KwData{\textbf{queue} queue, \textbf{time} $t, t_p$}
 


@@ -174,8 +178,9 @@ can just append it to the queue.
                }
        }
        \caption{Engine pseudocode for the \gls{C}- and
                }
        }
        \caption{Engine pseudocode for the \gls{C}- and

-               \gls{iTasks}-backend}\label{lst:engine}
+               \gls{iTasks}-view}\label{lst:engine}

 \end{algorithm}
 \end{algorithm}

+~\\

 
 To achieve this in the \gls{EDSL} a \gls{Task} class is added that work in a
 similar fashion as the \texttt{sds} class. This class is listed in
 
 To achieve this in the \gls{EDSL} a \gls{Task} class is added that work in a
 similar fashion as the \texttt{sds} class. This class is listed in


@@ -201,7 +206,10 @@ to a particular view and therefore are of the type \CI{View t r}. The
 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
 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.
+expression but now using the assignment style \gls{GPIO} technique. The
+\CI{thermostat} example also shows that it is not necessary to run everything
+as a \CI{task}. The main program code can also just consist of the contents of
+the root \CI{main} itself.

 
 \begin{lstlisting}[%
        label={lst:exmtask},caption={Some example \glspl{mTask}}]
 
 \begin{lstlisting}[%
        label={lst:exmtask},caption={Some example \glspl{mTask}}]