Index: /reasoner/reasoner.tex
===================================================================
--- /reasoner/reasoner.tex	(revision 136)
+++ /reasoner/reasoner.tex	(revision 137)
@@ -413,5 +413,4 @@
 \newcommand\problemRecords[0]{m}
 
-%(the relevant constraints per type $\relevantConstraintsPerType$ and the relevant constraint variables per decision variable ($\relevantConstraintVariables$)
 The reasoner performs forward reasoning, i.e., it identifies relevant constraints according to the reasoning mode, translates the constraints, stores constraint relations, evaluates the translated constraints in a loop until all constraints are processed and adjusts/extends the constraint set upon variable value changes.  Figure \ref{figStructure} shows the call graph of the reasoner algorithms and the sections where we will discuss them in more detail. Some algorithms call others recursively due to the potentially recursive structure of some IVML types, in particular compounds and containers. Algorithm \ref{algAddConstraint} and \ref{algComposeExpression} appear disconnected, but are called by most of the translation algorithms to populate the constraint base and to compose complex constraints from recursive nesting of containers and compounds. 
 
@@ -433,8 +432,9 @@
 \begin{algorithm}[H]
   \SetAlgoLined
-  \KwIn{configuration $cfg$}
-  \KwData{expression evaluator $e$, scope assignments $\scopeAssignments$, start time $startTime$, $reuse$ flag, constraint base copy $base_c, base_{\relevantConstraintsPerType}, base_{\relevantConstraintVariables}$, $projects$ sequence, $hasTimeout$ and $stop$ flags, constraints relations $\relevantConstraintsPerType$ and $\relevantConstraintVariables$, problem records $\problemRecords$}
+  \KwIn{configuration $c$}
+  \KwData{configuration $cfg$, expression evaluator $e$, scope assignments $\scopeAssignments$, start time $startTime$, $reuse$ flag, constraint base copy $base_c, base_{\relevantConstraintsPerType}, base_{\relevantConstraintVariables}$, $projects$ sequence, $hasTimeout$ and $stop$ flags, constraints relations $\relevantConstraintsPerType$ and $\relevantConstraintVariables$, problem records $\problemRecords$}
   \KwResult{Reasoning result $r$}
   
+  $cfg\assng c$\; \label{algMainLoopSetupVar}
   %evaluator.init()\;
   %evaluator.setResolutionListener(Algorithm \ref{algVarChange})\;
@@ -467,5 +467,5 @@
 \end{algorithm}
 
-First, Algorithm \ref{algMainLoop} sets up\footnote{In the implementation, the listener for changed variables triggering constraint re-scheduling (Algorithm \ref{algVarChange} in Section \ref{sectTopLevelConstraintsRescheduling}) as well as recording of assigned variables are registered with the expression evaluator. These details are omitted here.} the expression evaluator in line \ref{algMainLoopSetupEval} for use with the configuration $cfg$ and the scope assignments $\scopeAssignments$. In line \ref{algMainLoopStartTime} it stores the start time to terminate potentially endless loops induced by ping-pong assignments among constraints within a given maximum time. The remainder of the algorithm is separated into two parts, the full execution (lines \ref{algMainLoopFullStart}-\ref{algMainLoopFullEnd}), and the incremental part (lines \ref{algMainLoopIncStart}-\ref{algMainLoopIncEnd}) utilizing a constraint base prepared and stored while running the first part.
+First, Algorithm \ref{algMainLoop} sets up the global configuration variable $cfg$ and  the expression evaluator\footnote{In the implementation, the listener for changed variables triggering constraint re-scheduling (Algorithm \ref{algVarChange} in Section \ref{sectTopLevelConstraintsRescheduling}) as well as recording of assigned variables are registered with the expression evaluator. These details are omitted here.} in lines \ref{algMainLoopSetupVar}-\ref{algMainLoopSetupEval} for use with the configuration $cfg$ and the scope assignments $\scopeAssignments$. In line \ref{algMainLoopStartTime} it stores the start time to terminate potentially endless loops induced by ping-pong assignments among constraints within a given maximum time. The remainder of the algorithm is separated into two parts, the full execution (lines \ref{algMainLoopFullStart}-\ref{algMainLoopFullEnd}), and the incremental part (lines \ref{algMainLoopIncStart}-\ref{algMainLoopIncEnd}) utilizing a constraint base prepared and stored while running the first part.
 
 As shown in Algorithm \ref{algMainLoop}, first structures are created to store constraints for reuse (if $reuse$ is enabled), here for copying the constraint base ($base_c$), the relevant constraints per type ($base_{\relevantConstraintsPerType}$) and the relevant constraint variables per decision variable ($base_{\relevantConstraintVariables}$). Then,  the reasoner\footnote{In the implementation, translation and reasoning happen in \class{Resolver.java}.} must take the structure of IVML models into account, which is determined by the top-level IVML project making up $cfg$ and a cycle-free traversal of the imports of the top-level project. $discoverProjects(cfg)$ (line \ref{algMainLoopDiscover}, not further detailed in this document), performs a depth-first traversal of the import structure, ignores already seen cyclic imports and returns the processing sequence of all projects involved in $cfg$, i.e., the imported projects sorted in ascending manner according to their number of import dependencies. The main reasoning loop processes this project sequence as long as no timeout occurred (global flag $hasTimeout$) or the user requests a stop of the reasoning (global flag $stop$).
@@ -473,5 +473,5 @@
 For each project $p$, the main loop (lines \ref{algMainLoopStart} - \ref{algMainLoopEnd}) translates the constraints in $p$ and populates the constraint base as a side effect of the constraint translation called in line \ref{algMainLoopTranslate} (detailed in Section \ref{sectTopLevelConstraintsTranslation}). If enabled through $reuse$, the constraint translation stores the respective population of constraints in $base_c$ and their relations in $base_{\relevantConstraintsPerType}$ and $base_{\relevantConstraintVariables}$. Then the algorithm performs a forward-chaining evaluation of the constraint base in line \ref{algMainLoopEvaluate} (explained in Section \ref{sectTopLevelConstraintsEvaluation}). If a constraint changes a configuration variable as a side effect, the constraints related to that variable are re-scheduled for evaluation (detailed by Algorithm \ref{algVarChange} in Section \ref{sectTopLevelConstraintsRescheduling}). As last step for a project $p$, the algorithm freezes the actual values according to the (conditional) freeze-block specifications in $p$ in line \ref{algMainLoopFreeze}. 
 
-In incremental execution (lines \ref{algMainLoopIncStart}-\ref{algMainLoopIncEnd}), it is sufficient to reset the constraint relations in lines \ref{algMainLoopResetRelStart}-\ref{algMainLoopResetRelEnd}, to iterate over all stored projects in $base_c$. For each project, the algorithm takes over the respective constraints from $base_c$  into the actual constraint base, and, as before, evaluates the constraints and freezes the variables.
+In incremental execution (lines \ref{algMainLoopIncStart}-\ref{algMainLoopIncEnd}), it is sufficient to reset the constraint relations in lines \ref{algMainLoopResetRelStart}-\ref{algMainLoopResetRelEnd}, i.e., the relevant constraints per type $\relevantConstraintsPerType$ and the relevant constraint variables per decision variable $\relevantConstraintVariables$, to iterate over all stored projects in $base_c$. For each project, the algorithm takes over the respective constraints from $base_c$  into the actual constraint base, and, as before, evaluates the constraints and freezes the variables.
 
 Finally, after all projects have been considered or the main reasoning loop has been terminated prematurely, the algorithm composes\footnote{In the implementation, this is done in \class{Engine.java}, the actual reasoner instance, which creates and utilizes instances of \class{Resolver.java}.} in line \ref{algMainLoopResult} a detailed reasoning result based on recorded evaluation problems. This reasoning result also indicates a successful or failed execution, in particular whether a timeout occurred or a user-requested cancellation was requested.
@@ -528,10 +528,19 @@
 \subsection{Top-level Constraints Translation}\label{sectTopLevelConstraintsTranslation}
 
-The core idea of the constraint translation is to collect the constraints following the structure of an IVML model and to replace each type-related variable by the correct accessor expression for a global variable in the current scope. According to the IVML specification \cite{IVML-LS}, the relevant top-level elements\footnote{These elements can technically be identified through a model visitor.} are variable declarations, global constraints, annotation assignment blocks and eval-blocks. Type definitions are considered when when processing variable declarations, as the individual type of a variable indicates the specific constraints to be collected and instantiated.
+The core idea of the constraint translation is to collect the constraints following the structure of an IVML model and to replace each type-related variable by the correct accessor expression for a global variable in the current scope. According to the IVML specification \cite{IVML-LS}, the relevant top-level elements are variable declarations, global constraints, annotation assignment blocks and eval-blocks. Type definitions are considered when when processing variable declarations, as the individual type of a variable indicates the specific constraints to be collected and instantiated.
+
+Algorithm \ref{algTranslateConstraints} illustrates the top-level constraint translation. As a side effect, the constraint translation identifies and translates the constraints in the respective project\footnote{The top-translation steps in this algorithm are realized in the implementation by an IVML model visitor implicitly identifying and handling the types without iterating over the project multiple times as the notation here might suggest.}. To prioritize the constraints correctly, the reasoner uses four global sets, which are populated during the constraint translation and, finally, in Algorithm \ref{algTranslateConstraints} added to the constraint base. In more details, the reasoner maintains the following temporary constraint sets 
+
+\begin{enumerate}
+  \item \emph{Default constraints $\defaultConstraints$} containing constraints setting the default values of all variables. In particular, this set can contain constraints that assign compound and container initializers, i.e., modify multiple values at once.
+  \item \emph{Deferred default constraints $\deferredDefaultConstraints$} containing default initialization constraints to be evaluated after all constraints in $\defaultConstraints$, but before the remaining two constraint sets below. $\deferredDefaultConstraints$ is required as setting individual variables may be accidentally overridden by compound and container initializers assigned through constraints in $\defaultConstraints$.
+  \item \emph{Top level constraints $\topLevelConstraints$}, i.e., constraints directly specified in a project, in top-level eval-blocks, in top-level assignment blocks as well as constraints attached to top-level variables, e.g., through derived types. These constraints originating from the top-level scope shall take precedence over constraints in nested scopes~\cite{IVML-LS}.
+  \item \emph{Remaining other constraints $\otherConstraints$} in particular in in nested structures, including compound types used in containers, nested assignment blocks or constraint variables.
+\end{enumerate}
 
 \begin{algorithm}[H]
   \SetAlgoLined
   \KwIn{project $p$}
-  \KwData{constraint $base$, constraint base copy $base_c$, variable mapping $\variableMapping$, incremental mode flag $inc$, eval-blocks flag $inEval$}
+  \KwData{configuration $cfg$, constraint $base$, constraint base copy $base_c$, constraint sets $\defaultConstraints,\deferredDefaultConstraints, \topLevelConstraints, \otherConstraints$, eval-blocks flag $inEvals$}
 
      \tcp{start of model visitor}%>ConstraintTranslationVisitor
@@ -539,11 +548,11 @@
         $translateDeclaration(d, decision(cfg, d), \undef)$\; \label{algTranslateConstraintsTranslationDeclaration}
       }
-     $add(\topLevelConstraints, constraints(p), true)$\; \label{algTranslateConstraintsAdd} \label{algTranslateConstraintsTopLevelConstraints}
+     $add(\topLevelConstraints, constraints(p), true, \undef)$\; \label{algTranslateConstraintsAdd} \label{algTranslateConstraintsTopLevelConstraints}
      \ForAll{$a \iterAssng assignments(p)$}{
-        $add(\topLevelConstraints, constraints(a), true)$\; \label{algTranslateConstraintsTopLevelAnnotationConstraints}
+        $add(\topLevelConstraints, constraints(a), true, \undef)$\; \label{algTranslateConstraintsTopLevelAnnotationConstraints}
         $translateAnnotationAssignments(a, \undef, \undef, \undef)$\; \label{algTranslateConstraintsTopLevelAnnotationAssignments}
      } \label{algTranslateConstraintsTranslationEnd}
      $inEvals \assng true$\;
-     $add(\topLevelConstraints,\seqWith{constraints(e)}{e\in evals(p)}$\;\label{algTranslateConstraintsTopLevelEvals}
+     $add(\topLevelConstraints,\seqWith{constraints(e)}{e\in evals(p)}, true, \undef)$\;\label{algTranslateConstraintsTopLevelEvals}
      $inEvals \assng false$\;
      \tcp{end of model visitor}%<ConstraintTranslationVisitor
@@ -560,20 +569,10 @@
 \end{algorithm}
 
-Algorithm \ref{algTranslateConstraints} illustrates the top-level constraint translation. In full reasoning mode ($base_c = \undef$), Algorithm \ref{algTranslateConstraints} shall always be executed. If incremental reasoning based on a re-used constraint base is enabled, then this algorithm shall run only if there is no constraint base copy ($|base_c| = 0$), which is then created at the end of the algorithm. 
-
-The algorithm identifies and translates the constraints in the respective project\footnote{The top-translation steps in this algorithm are realized in the implementation by an IVML model visitor implicitly identifying and handling the types without iterating over the project multiple times as the notation here might suggest.}. To separate and prioritize the constraints, the reasoner uses several global sets, which are populated independently during the constraint translation and, in Algorithm \ref{algTranslateConstraints} added to the constraint base. In more details, the reasoner maintains the following temporary constraint sets 
-
-\begin{enumerate}
-  \item \emph{Default constraints $\defaultConstraints$} containing constraints setting the default values of all variables. In particular, this set can contain constraints that assign compound and container initializer, i.e., modify multiple values at once.
-  \item \emph{Deferred default constraints $\deferredDefaultConstraints$} containing default initialization constraints to be evaluated after all constraints in $\defaultConstraints$, but before the other usual constraints in $\topLevelConstraints$ and $\otherConstraints$. $\deferredDefaultConstraints$ is required as setting individual variables may be accidentally overridden by compound and container initializers assigned through constraints in $\defaultConstraints$.
-  \item \emph{Top level constraints $\topLevelConstraints$}, i.e., constraints directly specified in a project, constraints in top-level eval-blocks and their derived type constraints. These constraints, in particular project constraints as (virtual) top-level eval-block and top-level eval-block constraints shall take precedence over nested constraints~\cite{IVML-LS}.
-  \item \emph{Remaining usual constraints $\otherConstraints$} in nested structures, including compound types used in containers, constraint variables, or annotation constraints.
-\end{enumerate}
-
-These constraint sets are filled through the top-level calls in line \ref{algTranslateConstraintsTranslationStart}-\ref{algTranslateConstraintsTranslationEnd} including subsequent calls, prioritizing eval-blocks~\cite{IVML-LS}. Please note that adding constraints to a constraint set (currently) requires filtering out unneeded constraints as well as indexing used variables. This is done by the $add$ function (e.g., in line \ref{algTranslateConstraintsAdd}), which we will detail below in Section \ref{sectTranslation}. This algorithm also takes into account the $inEval$ flag prioritizing eval-block contents. According to the priority of the constraint sets introduced above, Algorithm \ref{algTranslateConstraints} composes the constraint base (keeping remaining constraints from prior project evaluations of the same configuration) in line \ref{algTranslateConstraintsCompose}. Finally, Algorithm \ref{algTranslateConstraints} clears the temporary constraint sets in lines \ref{algTranslateConstraintsClearSetsStart}-\ref{algTranslateConstraintsClearSetsEnd} and copies the constraint $base$ in the first run of the incremental reasoning mode with re-used constraint base.
-
-Adding constraints or sets of constraints to the constraint base involves constraint filtering in order to respect the incremental reasoning mode as well as constraints that initialize compounds and containers through respective initializer expressions. This is done by a specific operation, which we will discuss in Section \ref{sectContainerBase}. During algorithm discussion, we ill just use the respective function $add(s, c, b)$, which adds constraint $c$ to constraint set $s$, considering compound and container initialization expressions if $b = true$. Compound and container initialization expressions are a specific and relevant case here, as they represent complex compound or container values containing (interrelating) expressions that can only be evaluated during reasoning in contrast to constant values, which are already resolved by the IVML parser (or by a simple configuration initialization mechanism). These expressions are particularly important to correctly consider constraints stemming from constraint variables. While most translation algorithms rely on default values or actual values (e.g., through the $relevantValue$ function defined in Section \ref{sectNotationValues}, compound and container initializers can only be obtained from assignment constraints, i.e., completed and instantiated constraints, which are only available when adding constraints to a constraint set or the constraint base. Thus, We will skip container and compound initializers in the translation algorithms, focus on actual or constant default values, and finally consider these specific cases in Section \ref{sectContainerBase}.
-
-Finally, in line \ref{algTranslateConstraintsClearMapping}, algorithm \ref{algTranslateConstraints} clears the actual variable mapping $\variableMapping$ so that it can be re-used for translating the next IVML project.
+
+These constraint sets are filled as side effects of the calls in line \ref{algTranslateConstraintsTranslationStart}-\ref{algTranslateConstraintsTranslationEnd}. Please note that adding constraints to such a constraint set involves completing constraints through prefix quantification, identifying constraints from constraint variable values, filtering out unneeded constraints according to the reasoning mode as well as indexing constraints and their used variables. This is done by the $add$ function (e.g., in line \ref{algTranslateConstraintsAdd}), which we will detail below in Section \ref{sectContainerBase}. The $add$ function receives the target constraint set, the constraint(s) to add, a flag whether checking for constraint values is needed and an optional variable to which new constraints shall be related to (in $\relevantConstraintsPerType$ and $\relevantConstraintVariables$). The $add$ function considers the $inEvals$ flag\footnote{We follow here the implementation, where the visitor is an own class communicating this information via an instance variable.}, which enforces a higher priority for (eval) constraints to be added. According to the priority of the constraint sets introduced above, Algorithm \ref{algTranslateConstraints} composes in line \ref{algTranslateConstraintsCompose} the constraint base (keeping remaining constraints from prior project evaluations on the same configuration). Finally, Algorithm \ref{algTranslateConstraints} clears the temporary constraint sets in lines \ref{algTranslateConstraintsClearSetsStart}-\ref{algTranslateConstraintsClearSetsEnd} and copies the constraint $base$ in the first run of the incremental reasoning mode with re-used constraint base.
+
+%Adding constraints or sets of constraints to the constraint base involves constraint filtering in order to respect the incremental reasoning mode as well as constraints that initialize compounds and containers through respective initializer expressions. This is done by a specific operation, which we will discuss in Section \ref{sectContainerBase}. During algorithm discussion, we ill just use the respective function $add(s, c, b)$, which adds constraint $c$ to constraint set $s$, considering compound and container initialization expressions if $b = true$. Compound and container initialization expressions are a specific and relevant case here, as they represent complex compound or container values containing (interrelating) expressions that can only be evaluated during reasoning in contrast to constant values, which are already resolved by the IVML parser (or by a simple configuration initialization mechanism). These expressions are particularly important to correctly consider constraints stemming from constraint variables. While most translation algorithms rely on default values or actual values (e.g., through the $relevantValue$ function defined in Section \ref{sectNotationValues}, compound and container initializers can only be obtained from assignment constraints, i.e., completed and instantiated constraints, which are only available when adding constraints to a constraint set or the constraint base. Thus, We will skip container and compound initializers in the translation algorithms, focus on actual or constant default values, and finally consider these specific cases in Section \ref{sectContainerBase}.
+
+Finally, in line \ref{algTranslateConstraintsClearMapping}, Algorithm \ref{algTranslateConstraints} clears the actual variable mapping $\variableMapping$ so that it can be re-used for translating the next IVML project.
 
 \subsection{Top-level Constraints Evaluation}\label{sectTopLevelConstraintsEvaluation}
@@ -683,5 +682,5 @@
            }
           \lIf{$\IVMLself{} \in dflt \vee isOverridenSlot(d)$}{$dfltS \assng \deferredDefaultConstraints$}\lElse{$dfltS \assng \defaultConstraints$} \label{algTranslateDeclarationTranslateSelf3}
-          $add(dfltS, \createDefaultConstraint{\varSubstitutionSelfVarMapping{\IVML{assign}(ac, dflt)}{f}})$\; \label{algTranslateDeclarationTranslateDefault}
+          $add(dfltS, \createDefaultConstraint{\varSubstitutionSelfVarMapping{\IVML{assign}(ac, dflt)}{f}}, true, v)$\; \label{algTranslateDeclarationTranslateDefault}
       }
       \uIf{$isCompound(t)$}{
@@ -724,5 +723,5 @@
     \varSubstitutionOtherVarMapping{\closedCases{\IVML{forAll(i:}c\IVML{)}, & \text{if } isC \\ 
                           c, &\text{else}}}{decl(t)=deref(t, i)} 
-    }}{c\in cs}, true)$\;
+    }}{c\in cs}, true, \undef)$\;
  \caption{Translating constraints for derived types (\IVML{translateDerivedDatatypeConstraints}).}\label{algTranslateDerivedDatatypeConstraints}
 \end{algorithm}
@@ -829,7 +828,7 @@
 \MISSING{Register constraints for creating compound constraints (value is constraint value) }\;
   $eval \assng \setWithFlat{allEvalConstraints(r)}{r\in allRefines^+(t) \text{ } \setminus \text{ } excludedTypes(t)}$\;\label{algTranslateCompoundDeclarationEvalStart}
-  $add(\otherConstraints, \setWith{attach(\createConstraint{\varSubstitutionSelfVarMapping{c}{f}}, currentType(\variableMapping))}{c\in eval}, true)$\;\label{algTranslateCompoundDeclarationEvalEnd}
+  $add(\otherConstraints, \setWith{attach(\createConstraint{\varSubstitutionSelfVarMapping{c}{f}}, currentType(\variableMapping))}{c\in eval}, true, v)$\;\label{algTranslateCompoundDeclarationEvalEnd}
   $cmp \assng \setWithFlat{allCompoundConstraints(r)}{r\in allRefines^+(t) \text{ } \setminus \text{ } excludedTypes(t)}$\;\label{algTranslateCompoundDeclarationAllStart}
-  $add(\otherConstraints, \setWith{attach(\createConstraint{\varSubstitutionSelfVarMapping{c}{f}}, currentType(\variableMapping))}{c\in cmp}, true)$\;\label{algTranslateCompoundDeclarationAllEnd}
+  $add(\otherConstraints, \setWith{attach(\createConstraint{\varSubstitutionSelfVarMapping{c}{f}}, currentType(\variableMapping))}{c\in cmp}, true, v)$\;\label{algTranslateCompoundDeclarationAllEnd}
 
  \caption{Translating compound content (\IVML{translateCompoundContent}).}\label{algTranslateCompoundContent}
@@ -864,5 +863,5 @@
       $val\assng relevantValue(d, v, inc)$\;
       \uIf{$isConstraint(t_b)$} {
-          $add(\otherConstraints, \setWith{\createConstraint{\varSubstitutionSelfVarMapping{e}{ca}}}{e \in allElements(val)}, true)$\; \label{algTranslateContainerDeclarationConstraintContainer}
+          $add(\otherConstraints, \setWith{\createConstraint{\varSubstitutionSelfVarMapping{e}{ca}}}{e \in allElements(val)}, true, v)$\; \label{algTranslateContainerDeclarationConstraintContainer}
       } \ElseIf{$isCompound(t_b)$} {\label{algTranslateContainerDeclarationCompoundContainerStart}
            \uIf{$val \neq \undef$} {
@@ -1029,5 +1028,5 @@
       \ForAll{$d \iterAssng slots(a)$} {
           $activate(\variableMapping, d)$\;
-          $add(\otherConstraints, \set{translateAnnotationAssignment(e, d, ca)}, false)$\;
+          $add(\otherConstraints, \set{translateAnnotationAssignment(e, d, ca)}, false, \undef)$\;
           $t \assng type(d)$\;
           $ac \assng \closedCases{
@@ -1044,5 +1043,5 @@
           \If{$isCompound(t)$} {
               \ForAll{$s \iterAssng slots(t)$} {
-                  $add(\otherConstraints, translateAnnotationAssignment(e, s, v, \createExpression{\IVMLMeta{acc}(a, s)}))$\;
+                  $add(\otherConstraints, translateAnnotationAssignment(e, s, v, \createExpression{\IVMLMeta{acc}(a, s)}), false, \undef)$\;
               }
           }
@@ -1088,5 +1087,5 @@
       \If {$c \neq \undef$} {
         $c \assng \createConstraintConstraint{\varSubstitutionSelfVarMapping{c}{f}}$\;
-        $add(\otherConstraints, \set{c}, true)$\;
+        $add(\otherConstraints, \set{c}, \neg isConst(c), v)$\;
         $registerConstraint(v, c)$\;
       }
@@ -1119,12 +1118,16 @@
 }
 
-When unconditionally assigning a value to a variable, the right side may be a complex expression determining the actual value of a collection or a compound.  In both cases, the contained values may be constraint values (not handled in \ref{sectConstraintVariables}), but also deeply nested values may be constraint values, e.g., a constraint value in a compound in collection used in a compound. These constraints contribute to the initial constraint base and may cause certain value changes that cannot just be achieved as a consequance of changing values in constraint re-scheduling (cf. Section \ref{sectTopLevelConstraintsRescheduling}). As the $add$ function is also called as part of re-scheduling, dynamic constraints discovered there and their initializers and values are treated similarly.
-
-\begin{algorithm}[H]
-  \KwIn{constraint sequence $s$, constraint $c$, perform initializers $check$}
+When unconditionally assigning a value to a variable, the right side may be a complex expression determining the actual value of a collection or a compound.  In both cases, the contained values may be constraint values (not handled in \ref{sectConstraintVariables}), but also deeply nested values may be constraint values, e.g., a constraint value in a compound in collection used in a compound. These constraints contribute to the initial constraint base and may cause certain value changes that cannot just be achieved as a consequence of changing values in constraint re-scheduling (cf. Section \ref{sectTopLevelConstraintsRescheduling}). As the $add$ function is also called as part of re-scheduling, dynamic constraints discovered there and their initializers and values are treated similarly.
+
+\begin{algorithm}[H]
+  \KwIn{constraint sequence $s$, constraint $c$, perform initializers $check$, variable $v$}
   \KwData{top level and other constraints $\topLevelConstraints, \otherConstraints$, variable mapping $\variableMapping$, relevant constraints $\relevantConstraintsPerType$ , incremental flag $inc$, evals flag $inEvals$}
   $c = composeExpression(\variableMapping, c)$\;
     \If{$check$}{
-          $\otherConstraints \assng \otherConstraints \addSeq check(rightSide(c), \variableMapping)$\;
+          \ForAll{d\iterAssng check(rightSide(c), \variableMapping)} {
+              $createConstraintVariableConstraint(d, \undef, \undef)$\;
+          }
+          $e\assng check(rightSide(c), \variableMapping)$
+          $add(\otherConstraints, e, const(e) \neq \undef, v$\;
     }
     \If{$\closedCases{\neg isAssignment(c) \vee \neg isFrozen(c) & \text{if } inc\\ true & \text{else}}$}{
@@ -1135,5 +1138,5 @@
     }
     \If{$\neg isSimpleConstraint(c)$}{
-      $\relevantConstraintsPerType \assng \relevantConstraintsPerType \cup \setWith{\mapEntry{v}{c}}{v\in variables(c)}$\; % assignConstraintsToVariables
+      $\relevantConstraintsPerType \assng \relevantConstraintsPerType \cup \setWith{\mapEntry{w}{c}}{w\in variables(c)}$\; % assignConstraintsToVariables
      }
     }