In order to give the semantics to these instructions, we need to extend the syntactic form of rules, used in the description of big-step operational smeantics. Instead of
where $\Gamma, \Gamma^\prime$~--- \emph{environments}. The structure of environments can be different in different cases; for now environment is just a program. Informally,
the semantics of control flow instructions can not be described in terms of just a current instruction and current configuration~--- we need to take the whole
program into account. Thus, the enclosing program is used as an environment.
Additionally, for a program $P$ and a label $l$ we define a subprogram $P[l]$, such that $P$ is uniquely represented as $p^\prime(\llang{LABEL $\;l$})P[l]$.
In other words $P[l]$ is a unique suffix of $P$, immediately following the label $l$ (if there are multiple (or no) occurrences of label $l$ in $P$, then $P[l]$ is
undefined).
All existing rules have to be rewritten~--- we need to formally add a $\withenv{P}{\dots}$ part everywhere. For the new instructions the rules are given on Fig.~\ref{bs_sm_cc}.
With the structural control flow constructs already implemented, it is rather simple to ``saturate'' the language with more elaborated control constructs, using
the method of \emph{syntactic extension}. Namely, we may introduce the following constructs
\begin{lstlisting}
if $\;e_1\;$ then $\;s_1\;$
elif $\;e_2\;$ then $\;s_2\;$
$\dots$
elif $\;e_k\;$ then $\;s_k\;$
[ else $\;s_{k+1}\;$ ]
fi
\end{lstlisting}
and
\begin{lstlisting}
for $\;s_1$, $\;e$, $\;s_2\;$ do $\;s_3\;$ od
\end{lstlisting}
only at the syntactic level, directly parsing these constructs into the original abstract syntax tree, using the following conversions:
\begin{tabular}{p{3cm}p{1cm}p{3cm}}
\begin{lstlisting}
if $\;e_1\;$ then $\;s_1\;$
elif $\;e_2\;$ then $\;s_2\;$
$\dots$
elif $\;e_k\;$ then $\;s_k\;$
else $\;s_{k+1}\;$
fi
\end{lstlisting}&
\begin{center}
\vskip1cm
$\leadsto$
\end{center}&
\begin{lstlisting}
if $\;e_1\;$ then $\;s_1\;$
else if $\;e_2\;$ then $\;s_2\;$
$\dots$
else if $\;e_k\;$ then $\;s_k\;$
else $\;s_{k+1}\;$
fi
$\dots$
fi
\end{lstlisting}
\end{tabular}
\begin{tabular}{p{3cm}p{1cm}p{3cm}}
\begin{lstlisting}
if $\;e_1\;$ then $\;s_1\;$
elif $\;e_2\;$ then $\;s_2\;$
$\dots$
elif $\;e_k\;$ then $\;s_k\;$
fi
\end{lstlisting}&
\begin{center}
\vskip1cm
$\leadsto$
\end{center}&
\begin{lstlisting}
if $\;e_1\;$ then $\;s_1\;$
else if $\;e_2\;$ then $\;s_2\;$
$\dots$
else if $\;e_k\;$ then $\;s_k\;$
else skip
fi
$\dots$
fi
\end{lstlisting}
\end{tabular}
\begin{tabular}{p{5cm}p{1cm}p{3cm}}
\begin{lstlisting}
for $\;s_1$, $\;e$, $\;s_2\;$ do $\;s_3\;$ od
\end{lstlisting}&
\begin{center}
$\leadsto$
\end{center}&
\begin{lstlisting}
$s_1$;
while $\;e\;$ do
$s_3$;
$s_2$
od
\end{lstlisting}
\end{tabular}
The advantage of syntax extension method is that it makes it possible to add certain constructs with almost zero cost~--- indeed, no steps have to be made in order
to implement the extended constructs (besides parsing). Note, the semantics of extended constructs is provided for free as well (which is not always desirable).
Another potential problem with syntax extensions is that they can easily provide unreasonable results. For example, one may be tempted to implement a post-condition
loop using syntax extension:
\begin{tabular}{p{5cm}p{1cm}p{3cm}}
\begin{lstlisting}
repeat $\;s$ until $\;e$
\end{lstlisting}&
\begin{center}
$\leadsto$
\end{center}&
\begin{lstlisting}
$s$;
while $\;e\;$ == 0 do
$s$
od
\end{lstlisting}
\end{tabular}
However, for nested \lstinline{repeat} constructs the size of extended program is exponential w.r.t. the nesting depth, which makes the whole idea unreasonable.
