+A domain-specific language (DSL) is a programming language or executable
+specification language that offers, through appropriate notations and
+abstractions, expressive power focused on, and usually restricted to, a
+particular problem domain~\cite{van2002domain}. The DSL for the robot is
+designed so that the robot is able to perform multiple missions consisting of
+behaviours. A mission is basically a set of behaviours operating following the
+subsumption architecture assisted by a special purpose behaviour that shuts
+down the runtime to make room for a new mission. The complete grammar of the
+DSL can be found in \autoref{lst:grammar}.
+
+\autoref{fig:dsl} describes the hierarchy of the grammar. A \emph{Robot} is a
+set of constants combined with a list of \emph{Behaviour}s and a list of
+\emph{Mission}s. Missions consist of a \emph{StoppingCondition} and a list of
+references to \emph{Behaviour}. A \emph{Behaviour} is a literal representation
+of our interpretation of the subsumption architecture. Thus a control predicate
+and a sequence of \emph{Action}s.
+
+\emph{Action}s represent the real action the robot will perform. This can be an
+external action such as moving motors but also an internal action such as
+waiting or set something in memory.
+\emph{StopppingCondition}s are logical expression that can contain values from
+sensors or queries on the memory. To limit the complexity of the grammar a
+prefix notation is used for binary and unary operators.
+
+\begin{figure}[H]
+ \centering
+ $\xymatrix{
+ & *+[F]{Robot - Constants}\ar[dl]\ar[d]\ar[dr]\\
+ *+[F]{Mission_{\ldots}} & *+[F]{Mission_k}\ar[dl]\ar[d]\ar[dr]\ar[drr] & *+[F]{Mission_{\ldots}}\\
+ *+[F]{StoppingExpression} & *+[F]{Behaviour_{\ldots}} & *+[F]{Behaviour_k}\ar[dl]\ar[d] & *+[F]{Behaviour_{\ldots}}\\
+ & *+[F]{StoppingExpression} & *+[F]{Action_1}\ar[d]\\
+ && *+[F]{Action_2}\ar[d]\\
+ && *+[F]{Action_{\ldots}}\\
+ }$
+ \caption{Robot Domain Specific Language}\label{fig:dsl}
+\end{figure}
+
+To assist the user programming in the DSL small validation mechanism have been
+added. It could happen that the user specifies a mission that contains two
+behaviours both want control at all times. A behaviour that wants control at
+all times can be a valid design but when there are two with that property, only
+one will be used. To avoid such situations the IDE will warn the user when this
+is the case. The full code for the code validation can be found in
+\autoref{lst:val}. The full DSL instance used in the demonstration can be found
+in \autoref{lst:inst}.
+
+\subsection{Code Structure}
+The complete code generation code can be found in \autoref{lst:gen}. The
+following enumeration shows what is specifically generated per grammar object.
+All generated code can not function without the library. The library is an
+entire runtime that only needs a little amount of data plugged in to function
+as the program of a robot.