add bigger mtask example

[msc-thesis1617.git] / mtaskext.bytecode.tex

diff --git a/mtaskext.bytecode.tex b/mtaskext.bytecode.tex
index 111be6f..887a6b5 100644 (file)
--- a/mtaskext.bytecode.tex
+++ b/mtaskext.bytecode.tex
@@ -4,7 +4,7 @@ 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
-and is unique to a device.  The state contains fresh variable names and a
+and is unique to a device. The state contains fresh variable names and a
 register of \glspl{SDS} that are used.
 
 Types implementing the \gls{mTask} classes must have two free type variables.
@@ -30,13 +30,14 @@ same detection if necessary.
 :: ByteCode a p = BC (RWS () [BC] BCState ())
 :: BCValue = E.e: BCValue e & mTaskType, TC e
 :: BCShare =
-       { sdsi :: Int
-       , sdsval :: BCValue
+       { sdsi    :: Int
+       , sdsval  :: BCValue
+       , sdsname :: String
        }
 :: BCState = 
        { freshl :: Int
        , freshs :: Int
-       , sdss :: [BCShare]
+       , sdss   :: [BCShare]
        }
 
 class toByteCode a :: a -> String
@@ -188,11 +189,13 @@ instance retrn ByteCode where
 
 \subsection{Shared Data Sources \& Assignment}
 Fresh \gls{SDS} are generated using the state and constructing one involves
-multiple steps.  First, a fresh identifier is grabbed from the state.  Then a
+multiple steps. First, a fresh identifier is grabbed from the state.  Then a
 \CI{BCShare} record is created with that identifier. A \CI{BCSdsFetch}
 instruction is written and the body is generated to finally add the \gls{SDS}
 to the actual state with the value obtained from the function. The exact
-implementation is shown in Listing~\ref{lst:shareview}.
+implementation is shown in Listing~\ref{lst:shareview}. The implementation for
+the \CI{namedsds} class is exactly the same other than that it stores the given
+name in the \CI{BCShare} structure as well.
 
 \begin{lstlisting}[label={lst:shareview},%
        caption={Bytecode view for \texttt{arith}}]
@@ -200,7 +203,7 @@ freshshare = get >>= \st=:{freshs}->put {st & freshs=freshs+1} >>| pure freshs
 
 instance sds ByteCode where
        sds f = {main = BC (freshshare
-                       >>= \sdsi->pure {BCShare|sdsi=sdsi,sdsval=BCValue 0}
+                       >>= \sdsi->pure {BCShare|sdsname="",sdsi=sdsi,sdsval=BCValue 0}
                        >>= \sds->pure (f (tell` [BCSdsFetch sds]))
                        >>= \(v In bdy)->modify (addSDS sds v)
                        >>| unBC (unMain bdy))
@@ -211,11 +214,11 @@ instance sdspub ByteCode where
 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
+All assignable types compile to an \gls{RWST} which writes the specific fetch
 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
+correctly embedded \gls{SDS}. Assigning to an analog pin will result in the
 \gls{RWST} containing the \CI{BCAnalogRead} instruction. When the operation on
 the assignable is not a read operation from but an assign operation, the
 instruction(s) will be rewritten accordingly. This results in a \CI{BCSdsStore}