X-Git-Url: https://git.martlubbers.net/?a=blobdiff_plain;f=results.mtask.tex;h=acc6a6920518912613e394a339149092c7fee836;hb=eb79b5ec5410cf3e7fb8dd3b4f68517dcfb4fec6;hp=6496b7303fc0ee48923daf42f1d2ed42b4e71613;hpb=c7dbfdf743febd94770d3ce10d7d532a6bdd94cc;p=msc-thesis1617.git

diff --git a/results.mtask.tex b/results.mtask.tex
index 6496b73..acc6a69 100644
--- a/results.mtask.tex
+++ b/results.mtask.tex
@@ -1,11 +1,11 @@
-The \glspl{Task} suitable for a client are called \glspl{mTask} and are written
-in the aforementioned \gls{mTask}-\gls{EDSL}. Some functionality of the
-original \gls{mTask}-\gls{EDSL} will not be used in this system. Conversely,
-some functionality needed was not available in the existing \gls{EDSL}. Due to
-the nature of class based shallow embedding this obstacle is 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.
+The \glspl{Task} suitable for a client are called \gls{mTask}-\gls{Task} and
+are written in the aforementioned \gls{mTask}-\gls{EDSL}. Some functionality of
+the original \gls{mTask}-\gls{EDSL} will not be used in this system.
+Conversely, some functionality needed was not available in the existing
+\gls{EDSL}. Due to the nature of class based shallow embedding this obstacle is
+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{\gls{Task} Semantics}
 The current \gls{mTask} engine for devices does not support \glspl{Task} in the
@@ -41,7 +41,7 @@ reflected in the \CI{MTTask} message type.
 \Glspl{SDS} on a client are available on the server as well as regular
 \glspl{SDS}. However, the same freedom is not given for \glspl{SDS} that
 reside on the client. Not all types are suitable to be located on a client,
-simply because it needs to be serializable and representable on clients.
+simply because it needs to be representable on clients.
 Moreover, \glspl{SDS} behave a little different in an \gls{mTask} device
 compared to in the \gls{iTasks} system. In an \gls{iTasks} system, when the
 \gls{SDS} is updated, a broadcast to all watching \glspl{Task} in the system
@@ -63,9 +63,9 @@ class sdspub v where
 \end{lstlisting}
 
 \section{Bytecode compilation view}\label{sec:compiler}
-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 view is
-added to the \gls{mTask}-system encapsulated in the type \CI{ByteCode}. As
+The \gls{mTask}-\glspl{Task} 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 view
+is added to the \gls{mTask}-system encapsulated in the type \CI{ByteCode}. As
 shown in Listing~\ref{lst:bcview}, the \CI{ByteCode} view is a boxed \gls{RWST}
 that writes bytecode instructions (\CI{BC}, Subsection~\ref{sec:instruction})
 while carrying around a \CI{BCState}. The state is kept between compilations
@@ -118,7 +118,7 @@ instance serial ByteCode
 
 \subsection{Instruction Set}\label{sec:instruction}
 The instruction set is given in Listing~\ref{bc:instr}. The instruction set is
-kept large, but under $255$, to get as much expressieve power as possible while
+kept large, but under $255$, to get as much expressive power as possible while
 keeping all instruction within one byte.
 
 The interpreter running in the client is a stack machine. The virtual
@@ -232,13 +232,13 @@ instance noOp ByteCode where
 	noOp = tell` [BCNop]
 \end{lstlisting}
 
-The semantics for the \glspl{mTask} bytecode view are different from the
-semantics of the \gls{C} view. \glspl{Task} in the \gls{C} view can start new
-\glspl{Task} or even start themselves to continue, while in the bytecode view,
-\glspl{Task} run indefinitly, one-shot or on interrupt. To allow interval and
-interrupt \glspl{Task} to terminate, a return instruction is added. This class
-was not available in the original system and is thus added. It just writes a
-single instruction so that the interpreter knows to stop execution.
+The semantics for the \gls{mTask}-\glspl{Task} bytecode view are different from
+the semantics of the \gls{C} view. \glspl{Task} in the \gls{C} view can start
+new \glspl{Task} or even start themselves to continue, while in the bytecode
+view, \glspl{Task} run indefinitely, one-shot or on interrupt. To allow interval
+and interrupt \glspl{Task} to terminate, a return instruction is added. This
+class was not available in the original system and is thus added. It just
+writes a single instruction so that the interpreter knows to stop execution.
 Listing~\ref{lst:return} shows the classes and implementation for the return
 expression.
 
@@ -277,7 +277,7 @@ addSDS sds v s = {s & sdss=[{sds & sdsval=BCValue v}:s.sdss]}
 \end{lstlisting}
 
 All assignable types compile to a \gls{RWST} which writes the specific fetch
-instruction(s). For example, using a \gls{SDS} always results in an expression
+instruction(s). For example, using an \gls{SDS} always results in an expression
 of the form \CI{sds \x=4 In ...}. The actual \CI{x} is the \gls{RWST} that
 always writes one \CI{BCSdsFetch} instruction with the correctly embedded
 \gls{SDS}.  Assigning to an analog pin will result in the \gls{RWST} containing
@@ -350,4 +350,3 @@ position in the program memory.
 17-19: BCPush (Bool 0)             //Else label
 20   : BCDigitalWrite (Digital D0)
 \end{lstlisting}
-\todo{More elaborate example}