Index: /reasoner/consTranslation.tex
===================================================================
--- /reasoner/consTranslation.tex	(revision 197)
+++ /reasoner/consTranslation.tex	(revision 198)
@@ -26,11 +26,5 @@
 In Algorithm \ref{algTranslateDeclaration}, we apply the translation patterns above: Let $v$ be a variable with default value expression $deflt$. The first transformation pattern above turns $deflt$ into an assignment constraint. If $v$ is nested in a compound or a sequence, a qualified access expression for $v$ is required in the resulting constraint. We indicate this in terms of the $access(e)$ function on the right side. $access(e)$ returns $e$ if $e$ is already (an accessor expression based on) a top-level variable. $access(e)$ turns $e$ into an accessor (path) expression based on a respective top-level variable. The second pattern refers to annotations. As introduced in Section \ref{sectNotationVarDecls}, annotations are variables denoting an orthogonal configuration dimension of 'ordinary' variables. Thus, an annotation $a$ is translated in the context of the underlying 'ordinary' variable named $v$ in the pattern, i.e., requires  a qualification based on $v$. In Algorithm \ref{algTranslateDeclaration}, we will focus on the first transformation pattern. As stated above, we will defer more complex translations to later sections, e.g., annotations to Section \ref{sectAnnotationDefaults}, as these algorithms can then re-use the more generic translation of variables discussed here.
 
-Algorithm \ref{algTranslateDeclaration} translates all constraints related to a given variable $v$ (and its declaration $d$) based on the actual type of $v$. As complex types such as compounds may occur, Algorithm \ref{algTranslateDeclaration} delegates such types to more specialized algorithms, which then use Algorithm \ref{algTranslateDeclaration} recursively for nested variable declarations (with a respective access expression $ca$ and an adequately prepared variable mapping $\variableMapping$). These specialized algorithms will be discussed in the following sections. Assignment constraints created in Algorithm \ref{algTranslateDeclaration} are stored either in the global set for default constraints $\defaultConstraints$ or the set for deferred default constraints $\deferredDefaultConstraints$.
-
-Algorithm \ref{algTranslateDeclaration} consists of three parts: identifying the actual type and preparing the variable mapping (lines \ref{algTranslateDeclarationInitStart}-\ref{algTranslateDeclarationInitEnd}), translating the default value expression (lines \ref{algTranslateDeclarationDefaultStart}-\ref{algTranslateDeclarationDefaultEnd}) and translating complex types (lines \ref{algTranslateDeclarationComplexStart}-\ref{algTranslateDeclarationComplexEnd}).
-
-In the first part, Algorithm \ref{algTranslateDeclaration} first declares some local variables in line \ref{algTranslateDeclarationDecl}, including the default value expression $e_d$ (ignored in incremental mode), the actual value of self $f$ (for compound types only, overridden in line \ref{algTranslateDeclarationTranslateSelf1}) and the compound translation mode ($c_m$, overridden in line \ref{algTranslateDeclarationRegisterCompound} for use in line \ref{algTranslateDeclarationTranslateCompound}).  
-
-In line \ref{algTranslateDeclarationRefinedType}, the actual type of the variable is determined, either based actual value (if a variable\footnote{\label{fnVariableNull}When initializing a configuration or creating constraints from a constant complex value expression, variables may not already be in place in all cases.} and a value is given), default value expression (as a type approximation of a missing value) or the declaration. If $t$ is a compound type, we set in line \ref{algTranslateDeclarationTranslateSelf1} the value of self $v$ to the actual variable declaration $d$ and create the variable mapping for all slots in line \ref{algTranslateDeclarationRegisterCompound} by calling Algorithm \ref{algTranslateCompoundDeclaration}. Typically, this creates a new context frame in the variable mapping $\variableMapping$, which must be correctly cleaned up at the end of Algorithm \ref{algTranslateDeclaration}. We indicate this by the compound mode $c_m$, which is adjusted here and considered in the translation call in line \ref{algTranslateDeclarationTranslateCompound}. 
+Algorithm \ref{algTranslateDeclaration} translates all constraints related to a given variable declaration $d$ and its configuration variable $v$, which may be $\undef$ for type-only translations\footnote{\label{fnVariableNull}When initializing a configuration or creating constraints from a  complex constant value expression, variables may not already be in place in all cases.}. Default value assignment constraints created in Algorithm \ref{algTranslateDeclaration} are stored either in the global set for default constraints $\defaultConstraints$ or the set for deferred default constraints $\deferredDefaultConstraints$. As the type of $v$ may be a complex type such as a compound, Algorithm \ref{algTranslateDeclaration} delegates these translations to more specialized algorithms, which use Algorithm \ref{algTranslateDeclaration} recursively. As thereby the translation context changes, the involved algorithms incrementally adjust the access expression $ca$ and the variable mapping $\variableMapping$. 
 
 \begin{algorithm}[H]
@@ -69,4 +63,8 @@
  \caption{Translating declarations (\IVML{translateDeclaration}).}\label{algTranslateDeclaration}
 \end{algorithm}
+
+Algorithm \ref{algTranslateDeclaration} consists of three parts: identifying the actual type and preparing the variable mapping (lines \ref{algTranslateDeclarationInitStart}-\ref{algTranslateDeclarationInitEnd}), translating the default value expression (lines \ref{algTranslateDeclarationDefaultStart}-\ref{algTranslateDeclarationDefaultEnd}) and translating complex types (lines \ref{algTranslateDeclarationComplexStart}-\ref{algTranslateDeclarationComplexEnd}).
+
+In the first part, Algorithm \ref{algTranslateDeclaration} declares some local variables in line \ref{algTranslateDeclarationDecl}, including the default value expression $e_d$ (ignored in incremental mode), the actual value of \IVMLself{} called here $f$ (for compounds only) and the compound translation mode $c_m$ (initially $NONE$). In line \ref{algTranslateDeclarationRefinedType}, the actual type of $v$ is determined, either based on the value of $v$, the default value expression (as an approximation) or $d$. If $t$ is a compound type, we set in line \ref{algTranslateDeclarationTranslateSelf1} the value of \IVMLself{} to the actual variable declaration $d$ and create the variable mapping for all slots in line \ref{algTranslateDeclarationRegisterCompound} by calling Algorithm \ref{algTranslateCompoundDeclaration}. Typically, this creates a new context frame in the variable mapping $\variableMapping$, which must be correctly cleaned up at the end of Algorithm \ref{algTranslateDeclaration} (controlled by the compound mode $c_m$). 
 
 A remaining default value expression $e_d$ is turned into an assignment constraint if $d$ is not an attribute used within an assignment block (this may otherwise collide with default values defined by the assignment block). If the $v$ variable is a constraint variable, we also have to add $e_d$ to the constraint base. This is done by calling Algorithm \ref{algCreateConstraintVariableConstraint} (cf. Section \ref{sectConstraintVariables}). Then, we turn the default value expression into an assignment expression. However, the creation of the sub-expression $ac$ representing the variable $v$ technically depends on whether $d$ is a (nested) annotation or 'ordinary' variable (lines \ref{algTranslateDeclarationCreateACStart}-\ref{algTranslateDeclarationCreateACEnd}). Further, we must determine the constraint set for adding the assignment constraint (line \ref{algTranslateDeclarationTranslateSelf3}): We add the constraint to $\deferredDefaultConstraints$ if the assignment may override a previous value assignment through a complex value. This is (potentially) the case if \IVMLself{} is used in $e_d$ or if $d$ is an overridden slot that may be overriden accidentally by a complex compound value. Else, we add the constraint to the set of default constraints $\defaultConstraints$. Ultimately, we create an expression assigning $e_d$ to $ac$, substitute \IVMLself{} and the actual variable mapping in this assignment expression, turn the result into a default constraint and add it to the respective constraint set in line \ref{algTranslateDeclarationTranslateDefault}. 
