Sjaak Smetsers,
Steffen Michels,
Sven-Bodo Scholz,
-Tim Steenvoorden, and everyone else from department.
+Tim Steenvoorden, and everyone else from the department.
The many students that allowed and trusted me to (co) supervise them in their theses:
Arjen Nederveen,
Chris and Maudy;
Koen and Michelle;
Alba;
-\foreignlanguage{russian}{Александер};
+\foreignlanguage{russian}{Александр};
Annerieke;
Camil and Devika;
Emma;
\begin{lstHaskellLhstex}
print_0 :: Expr_0 -> String
print_0 (Lit_0 v) = show v
-print_0 (Add_0 e1 e2) = "(" ++ print_0 e1 ++ "-" ++ print_0 e2 ++ ")"
+print_0 (Add_0 e1 e2) = "(" ++ print_0 e1 ++ "+" ++ print_0 e2 ++ ")"
\end{lstHaskellLhstex}
While the language is concise and elegant, it is not very expressive.
It is implemented in the general-purpose lazy functional programming language \gls{CLEAN}, and therefore requires relatively powerful hardware.
The inflated hardware requirements are no problem for regular computers but impractical for the average edge device.
-This is where an additional \glspl{DSL} must play its part.
+This is where additional \glspl{DSL} must play their part.
\Glspl{DSL} are programming languages tailored to a specific domain.
Consequently, jargon is not expressed in terms of the language itself, but is built into the language.
Furthermore, the \gls{DSL} can eschew language or system features that are irrelevant for the domain.
The simulation allows the user to (partially) execute tasks, control the simulated peripherals, inspect the internal state of the tasks, and interact with \glspl{SDS}.
\begin{lstClean}[caption={The entry point for the simulation interpretation.},label={lst:simulatemain}]
-:: TraceTask a // from the mTask simulator library
-simulate :: (Main (TraceTask a)) -> [String]
+:: TraceTask a; :: TT a // from the mTask simulator library
+simulate :: (Main (TT a)) -> Task (TraceTask a)
\end{lstClean}
\begin{figure}