X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=methods.mtask.tex;h=6d1284872909509ff6e0b3196f18a487815d3f1c;hb=a4d108b9046bfd1d94e8b986a00c00090391d7b6;hp=3ef01f19d27a6c424b67786b1a64f8f1bccb07a5;hpb=36149fe97302e46248ceecfd8ef39faaea19991b;p=msc-thesis1617.git

diff --git a/methods.mtask.tex b/methods.mtask.tex
index 3ef01f1..6d12848 100644
--- 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}%
@@ -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.
 
-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}]
@@ -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
-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
@@ -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 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
@@ -122,10 +128,10 @@ class assign v where
   (=.) 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}.
@@ -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
-\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
-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
@@ -199,20 +205,20 @@ count = task \count = (\n.count (lit 1000) (n +. One)) In {main = count (lit 100
 \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}[%
-	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)