roy's comments: chapter 4
authorMart Lubbers <mart@martlubbers.net>
Mon, 26 Jun 2017 10:25:45 +0000 (12:25 +0200)
committerMart Lubbers <mart@martlubbers.net>
Mon, 26 Jun 2017 10:25:45 +0000 (12:25 +0200)
methods.mtask.tex
thesis.tex

index 72e66d1..3ef01f1 100644 (file)
@@ -8,22 +8,22 @@ for microcontrollers such as the \gls{Arduino}~\cite{koopman_type-safe_nodate}%
 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
-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}]
@@ -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
-and omitted in subsequent functions. 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}]
@@ -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 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}]
@@ -153,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
-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.
 
+~\\
 \begin{algorithm}[H]
        \KwData{\textbf{queue} queue, \textbf{time} $t, t_p$}
 
@@ -176,8 +178,9 @@ can just append it to the queue.
                }
        }
        \caption{Engine pseudocode for the \gls{C}- and
-               \gls{iTasks}-backend}\label{lst:engine}
+               \gls{iTasks}-view}\label{lst:engine}
 \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
@@ -204,9 +207,9 @@ 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. The
-\CI{thermostat} example also show 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.
+\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}}]
index be19044..782e142 100644 (file)
@@ -1,6 +1,6 @@
 %&thesis
 \usepackage[nonumberlist]{glossaries}  % Glossaries and acronyms
-\usepackage[]{algorithm2e}             % Pseudocode
+\usepackage[algochapter]{algorithm2e}             % Pseudocode
 \makeglossaries%
 
 \input{glossaries}