Index: /reasoner/reasoner.tex
===================================================================
--- /reasoner/reasoner.tex	(revision 105)
+++ /reasoner/reasoner.tex	(revision 106)
@@ -598,5 +598,5 @@
 If $t$ is a compound type, we set the value of self $v$ to the actual variable declaration $d$ and execute the specific translations for compound types using Algorithm \ref{algTranslateCompoundDeclaration}. If $t$ is a container type, we call \ref{algTranslateContainerDeclaration} instead. Otherwise, if there is a default value expression and reasoning is not in incremental mode, i.e., we shall translate default value expressions to assignment constraints, and if there is a compound accessor, we just have to schedule a replacement of \IVML{self} by the compound accessor. Remaining default constraints are taken over as defined as long as the reasoner is not operating incremental mode as there no default value assignments are needed.
 
-If there is finally a default value expression to be recorded in the constraint base and $d$ is not an attribute used within an assignment block(\MISSING{explain}), we have to distinguish whether the actual variable is a constraint variable or an usual variable. In the first case, we apply Algorithm \ref{algCreateConstraintVariableConstraint} (cf. Section \ref{sectConstraintVariables}). In the second case, we turn the default value expression into an assignment expression. However, the accessor creation depends on whether $d$ is an annotation or an usual variable. Then, we substitute \IVML{self} and the actual variable mapping on the complete constraint expression and turn the result into a default constraint. We either either it to $\deferredDefaultConstraints$ if the constraint may override a complete value assignment (\IVML{self} is used referring to another variable in the same compound or $d$ is an overridden slot that may accidentally be overriden by a complex compound value) or in all other cases to the usual default constraints set $\defaultConstraints$.
+If there is finally a default value expression to be recorded in the constraint base and $d$ is not an attribute used within an assignment block (this may otherwise collide with default values defined by the assignment block), we have to distinguish whether the actual variable is a constraint variable or an usual variable. In the first case, we apply Algorithm \ref{algCreateConstraintVariableConstraint} (cf. Section \ref{sectConstraintVariables}). In the second case, we turn the default value expression into an assignment expression. However, the accessor creation depends on whether $d$ is an annotation or an usual variable. Then, we substitute \IVML{self} and the actual variable mapping on the complete constraint expression and turn the result into a default constraint. We either either it to $\deferredDefaultConstraints$ if the constraint may override a complete value assignment (\IVML{self} is used referring to another variable in the same compound or $d$ is an overridden slot that may accidentally be overriden by a complex compound value) or in all other cases to the usual default constraints set $\defaultConstraints$.
 
 \subsection{Derived types}\label{sectDerivedTypes}
@@ -739,5 +739,5 @@
 There are two basic translation patterns for containers, 1) constraints induced by used types and 2) top-level constraints for collection variables. We will focus here on the first pattern, as the second pattern comes for free as part of the translation of the top-level constraints.
 
-As shown for the first pattern, given a container variable $v$, we consider all potential (declared) as well as used types in the actual value and create for each constraint implied by these types an all-quantified constraint over $v$. Please note that individual constraints are needed to provide detailed error messages, but also to keep the re-evaluation effort low. However, if the container is nested, i.e., $T$ is again a container over a certain type, we must take flattening into account to apply the constraints to the individual elements. Moreover, if $\subTypeOf{t}{T)}$, accessing specific properties such as compound slots requires some form of type casting / selection on the elements of the container. These additional container transformations depend on the actual container type and are represented in the schema by $f(v, t)$, which we will detail below in this section. Finally, the constraint must be substituted adequately, using the quantifier iterator to access the elements, including slot access expressions for compound element types as well as known access expressions to other variables and slots. 
+As shown for the first pattern, given a container variable $v$, we consider all potential (declared) as well as used types in the actual value and create for each constraint implied by these types an all-quantified constraint over $v$. Please note that individual constraints are needed to provide detailed error messages, but also to keep the re-evaluation effort low. However, if the container is nested, i.e., $T$ is again a container over a certain type, we must take flattening into account to apply the constraints to the individual elements. Moreover, if $\subTypeOf{t}{T)}$, accessing specific properties such as compound slots requires some form of type casting / selection on the elements of the container. These additional container transformations depend on the actual container type and are represented in the schema by $f(v, t)$. For short, $f(v, t)$ turns a sequence into a set to avoid duplicated constraints, flattens a nested container and applies type selects to enable access to slots defined in refined compounds. We will detail $f(v, t)$ below in this section. Finally, the constraint must be substituted adequately, using the quantifier iterator to access the elements, including slot access expressions for compound element types as well as known access expressions to other variables and slots. 
 
 \begin{algorithm}[H]
@@ -799,6 +799,9 @@
 
       $e\assng\closedCases{ca, & \text{if } ca \neq \undef\\\createExpression{d}, &\text{else}}$\; \label{algTranslateDefaultsCompoundContainerInitE}
+      \uIf{$isSequence(type(d))$} {
+        $e\assng\createExpression{\IVML{asSet}(e)}$\; \label{algTranslateDefaultsCompoundContainerAsSet}
+      }
       \uIf{$isNested(type(d))$} {
-        $e\assng\createExpression{\IVML{flatten}(d)}$\; \label{algTranslateDefaultsCompoundContainerFlatten}
+        $e\assng\createExpression{\IVML{flatten}(e)}$\; \label{algTranslateDefaultsCompoundContainerFlatten}
       }
       \uIf{$u\neq t$} {
@@ -814,5 +817,5 @@
 \end{algorithm}
 
-Algorithm \ref{algTranslateCompoundContainer} targets this by creating all-quantized constraints over all elements of the container, mostly be reusing Algorithm \ref{algRegisterCompoundMapping} to create a compound mapping and Algorithm \ref{algTranslateCompoundContent} to translate the compound content. Initially, we a local variable $l$ as later iterator variable for the quantifier expressions. Then, we create a prefix expression $e$ of the quantor constraint expression, i.e., we determine in line \ref{algTranslateDefaultsCompoundContainerInitE} the access expression to the collection either using $ca$ or just holding the variable of the container $d$. If the container is nested, we flatten it in line \ref{algTranslateDefaultsCompoundContainerFlatten} as constraints only need to be created for the elements (no specific constraints can be attached to a container type except for derived values, which are handled by Algorithm \ref{algTranslateDeclaration}). If the actual type $t$ is not the same as the type of the declaration $u)$, we must consider that the slot $s$ only exists for the specific refined type $t$. Then, the instantiation shall apply only to container elements of type $t$ (or of refined types), i.e., we insert in line \ref{algTranslateDefaultsCompoundContainerCast} an element selection by projecting the container to all elements of type $t$ (and refined types). 
+Algorithm \ref{algTranslateCompoundContainer} targets this by creating all-quantized constraints over all elements of the container, mostly be reusing Algorithm \ref{algRegisterCompoundMapping} to create a compound mapping and Algorithm \ref{algTranslateCompoundContent} to translate the compound content. Initially, we a local variable $l$ as later iterator variable for the quantifier expressions. Then, we create a prefix expression $e$ of the quantor constraint expression, i.e., we determine in line \ref{algTranslateDefaultsCompoundContainerInitE} the access expression to the collection either using $ca$ or just holding the variable of the container $d$. If the container is a sequence that may contain duplicates, we first turn it into a set to avoid accidentally duplicated constraints (line \ref{algTranslateDefaultsCompoundContainerFlatten}). If the container is nested, we flatten it in line \ref{algTranslateDefaultsCompoundContainerFlatten} as constraints only need to be created for the elements (no specific constraints can be attached to a container type except for derived values, which are handled by Algorithm \ref{algTranslateDeclaration}). If the actual type $t$ is not the same as the type of the declaration $u)$, we must consider that the slot $s$ only exists for the specific refined type $t$. Then, the instantiation shall apply only to container elements of type $t$ (or of refined types), i.e., we insert in line \ref{algTranslateDefaultsCompoundContainerCast} an element selection by projecting the container to all elements of type $t$ (and refined types). 
 
 Now we create a context for the container on the stack of $\variableMapping$. In contrast to compound translations, we also register the prefix expression $e$ and the iterator variable $l$. This will be taken up by the $add$ operation, which completes the full constraint from the given information on the stack, i.e., the full creation of the constraint is prepared but not shown in Algorithm \ref{algRegisterCompoundMapping}. As for compounds, we create now the compound mapping using Algorithm \ref{algTranslateCompoundContent}. Please note that slot access now happens via the iterator variable $l$, while annotation access happens through $ca$. Specifying $t$ also as target type avoids unnecessary type casts here. Then, we call Algorithm \ref{algTranslateCompoundContent} to translate the compound slots, implying translation of annotations as well as recursion over further compounds and containers. 
@@ -950,5 +953,5 @@
 }
 
-In more details, Algorithm \ref{algCreateConstraintVariableConstraint} translates a constraint (if not undefined, including the IVML \IVML{null} case, i.e., a de-configured constraint variable). Algorithm \ref{algCreateConstraintVariableConstraint} creates constraints through variable substitution with $\variableMapping$ and, if available, a respective value for \IVMLself (here $f$), turning the resulting expression into a constraint and adding it to the set of other constraints $\otherConstraints$. Moreover, the relationship between the underlying variable $v$ and the constraint must be recorded for efficient update of the constraint base upon value change (cf. Algorithm \ref{algVarChange}). Recording happens only if $v$ is defined, which may not be the case if this algorithm is called while processing container values.
+In more details, Algorithm \ref{algCreateConstraintVariableConstraint} translates a constraint (if not undefined, including the IVML \IVML{null} case, i.e., a de-configured constraint variable). Algorithm \ref{algCreateConstraintVariableConstraint} creates constraints through variable substitution with $\variableMapping$ and, if available, a respective value for \IVMLself (here $f$), turning the resulting expression into a constraint and adding it to the set of other constraints $\otherConstraints$. Moreover, the relationship between the underlying variable $v$ and the constraint must be recorded for efficient update of the constraint base upon value change (cf. Algorithm \ref{algVarChange}).
 
 \begin{algorithm}[H]
@@ -959,12 +962,8 @@
         $c \assng \createConstraint{\varSubstitutionSelfVarMapping{c}{f}}$\;
         $add(\otherConstraints, \set{c}, true)$\;
-        \If{$v \neq \undef$}{
-           \MISSING{map v to c for dynamic value type change}\;
-            $\relevantConstraints \assng \relevantConstraints \addMap \mapEntry{c}{v}$
-        } 
+        $registerConstraint(v, c)$\;
       }
  \caption{Creating constraints for constraint variables (\IVML{createConstraintVariableConstraint}).}\label{algCreateConstraintVariableConstraint}
 \end{algorithm}
-
 
 \subsection{Constraint base operations}\label{sectContainerBase}
@@ -1027,4 +1026,20 @@
 %\end{algorithm}
 
+\begin{algorithm}[H]
+  \SetAlgoLined
+  \KwIn{variable $v$, constraint expression $c$}
+  \KwData{other constraints $\otherConstraints$, relevant constraints $\relevantConstraints$}
+ 
+  \If{$v \neq \undef$}{
+       \MISSING{map v to c for dynamic value type change}\;
+       $\relevantConstraints \assng \relevantConstraints \addMap \mapEntry{c}{v}$\;
+       \MISSING{copied state}\;
+   } 
+
+ \caption{Registering constraints originating fom constraint variables (\IVML{registerConstraint}).}\label{algRegisterConstraint}
+\end{algorithm}
+%
+Recording happens only if $v$ is defined, which may not be the case if this algorithm is called while processing container values.
+
 \section{Constraint Re-scheduling}\label{sectTopLevelConstraintsRescheduling}
 
@@ -1294,5 +1309,5 @@
     \item \textbf{Reuse visitor instances} if applied more than once, in particular reasoners with more complex internal data structures such as maps or lists. This required some refactoring of the IVML model implementation.
     \item \textbf{Avoid temporary instances}, e.g., iterators, temporary constraint creation, temporary data structures wherever possible. One option replacing a collection structure is to define a functor for processing the elements and to create a reusable instance of that functor. If permitted by the Java environment settings (EASy often compiles against JDK 1.6), also a lambda-function instead of a heavy-weight functor class may be appropriated.
-    \item \textbf{Avoid multipe variable substitutions} per constraint expressions, i.e., join variable substitutions wherever possible. Variable substitution copies the expression. Multiple copies throws away the last copied expression.
+    \item \textbf{Avoid multipe variable substitutions} per constraint expressions, i.e., join variable substitutions wherever possible. Variable substitution copies the expression. Initially, performing a substitution multiple time on the same expression caused creating multiple copies of all nodes in memry, i.e., a follow-up copy usually was used instead of the original copy making the previous copies effectively superfluous. As sometimes multiple substitutions can only be avoided with additional (not straightforward) code, e.g., for a sequential call of Algorithm \ref{algTranslateCompoundDeclaration} and \ref{algTranslateDeclaration}, we revised the IVML expression copy mechanism to create instances of expression tree nodes only if a substitution happend, i.e., new expression trees are absolutely required.
     \item \textbf{Use instance pooling} if datastructures are temporarily used, e.g., variable accessors in expression evaluation or sets of compounds in reasoning (20-30 ms on larger models, at that time around 10\% of runtime).
 \end{itemize}