Merge branch 'master' of git.martlubbers.net:msc-thesis1617

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

diff --git a/methods.mtask.tex b/methods.mtask.tex
index 3ef01f1..6d12848 100644 (file)
--- a/methods.mtask.tex
+++ b/methods.mtask.tex
@@ -1,5 +1,5 @@
-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
+The \gls{mTask}-\gls{EDSL} is the language used for the proposed system. The
+\gls{mTask}-\gls{EDSL} was created by Koopman et al.\ and supports 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}%
 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}%


@@ -12,18 +12,18 @@ 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.
 
 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. 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}.
+A view for the \gls{mTask}-\gls{EDSL} is a type with two free type
+variables\footnote{kind \CI{*->*->*}.} that implements some of the classes
+given. The types do not have to be present as fields in the 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}]


@@ -70,7 +70,9 @@ in Listing~\ref{lst:control}. The first class of \emph{If} statements describes
 the regular \emph{if} statement. The expressions given can have any role. The
 functional dependency on \CI{s} determines the return type of the statement.
 The listing includes examples of implementations that illustrate this
 the regular \emph{if} statement. The expressions given can have any role. The
 functional dependency on \CI{s} determines the return type of the statement.
 The listing includes examples of implementations that illustrate this

-dependency.
+dependency. A special \emph{If} statement --- only used for statements --- is
+also added under the name \CI{IF}, of which the \CI{?} is a conditional
+statement to execute.

 
 The sequence operator is straightforward and its only function is to tie
 two expressions together. The left expression is executed first, followed by
 
 The sequence operator is straightforward and its only function is to tie
 two expressions together. The left expression is executed first, followed by


@@ -81,6 +83,10 @@ the right expression.
 class If v q r ~s where
   If :: (v Bool p) (v t q) (v t r) -> v t s | ...
 
 class If v q r ~s where
   If :: (v Bool p) (v t q) (v t r) -> v t s | ...
 

+class IF v where
+  IF :: (v Bool p) (v t q) (v s r) -> v () Stmt | ...
+  (?) infix 1 :: (v Bool p) (v t q) -> v () Stmt | ...
+

 instance If Code Stmt Stmt Stmt
 instance If Code e    Stmt Stmt
 instance If Code Stmt e    Stmt
 instance If Code Stmt Stmt Stmt
 instance If Code e    Stmt Stmt
 instance If Code Stmt e    Stmt


@@ -122,10 +128,10 @@ class assign v where
   (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ...
 \end{lstlisting}
 
   (=.) infixr 2 :: (v t Upd) (v t p) -> v t Expr | ...
 \end{lstlisting}
 

-A way of storing data in \glspl{mTask} is using \glspl{SDS}. \glspl{SDS} serve
-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
+One way of storing data in \gls{mTask}-\glspl{Task} is using \glspl{SDS}.
+\glspl{SDS} serve 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
 \gls{mTask} and make it recognizable by the type system by separating programs
 and decorations such as \glspl{SDS}.
 Listing~\ref{lst:sdsclass}. The \CI{Main} type is introduced to box an
 \gls{mTask} and make it recognizable by the type system by separating programs
 and decorations such as \glspl{SDS}.


@@ -142,12 +148,12 @@ class sds v where
 \section{Semantics}
 The \gls{C}-backend of the \gls{mTask}-system has an engine that is generated
 alongside the code for the \glspl{Task}. This engine will execute the
 \section{Semantics}
 The \gls{C}-backend of the \gls{mTask}-system has an engine that is generated
 alongside the code for the \glspl{Task}. This engine will execute the

-\glspl{mTask} according to certain rules and semantics.
-\glspl{mTask} do not behave like functions but more like
+\gls{mTask}-\glspl{Task} according to certain rules and semantics.
+\gls{mTask}-\glspl{Task} do not behave like functions but more like

 \gls{iTasks}-\glspl{Task}. An \gls{mTask} is queued when either its timer runs
 out or when it is launched by another \gls{mTask}. When an \gls{mTask} is
 \gls{iTasks}-\glspl{Task}. An \gls{mTask} is queued when either its timer runs
 out or when it is launched by another \gls{mTask}. When an \gls{mTask} is

-queued it does not block the execution and it will return immediately while
-the actual \gls{Task} will be executed anytime in the future.
+queued it does not block the execution and it will return immediately while the
+actual \gls{Task} will be executed anytime in the future.

 
 The \gls{iTasks}-backend simulates the \gls{C}-backend and thus uses the same
 semantics. This engine expressed in pseudocode is listed as
 
 The \gls{iTasks}-backend simulates the \gls{C}-backend and thus uses the same
 semantics. This engine expressed in pseudocode is listed as


@@ -199,20 +205,20 @@ count = task \count = (\n.count (lit 1000) (n +. One)) In {main = count (lit 100
 \end{lstlisting}
 
 \section{Example mTask}
 \end{lstlisting}
 
 \section{Example mTask}

-Some example \glspl{mTask} using almost all of their 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 \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 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.
+Some example \gls{mTask}-\glspl{Task} using almost all of their functionality
+are shown in Listing~\ref{lst:exmtask}. The \gls{mTask}-\glspl{Task} 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}
+blinking led 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 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}[%
 
 \begin{lstlisting}[%

-       label={lst:exmtask},caption={Some example \glspl{mTask}}]
+       label={lst:exmtask},caption={Some example \gls{mTask}-\glspl{Task}}]

 blink = task \blink=(\x.
                IF (x ==. lit True) (ledOn led) (ledOff led) :.
                blink (lit 1000) (Not x)
 blink = task \blink=(\x.
                IF (x ==. lit True) (ledOn led) (ledOff led) :.
                blink (lit 1000) (Not x)