Formal specification language are designed for formality, but not for execution. Consequently they include constructs, such as universal quantification, which are precisely defined but are not constructive. In other words there are constructs which cannot be mapped onto any (practical) algorithm.
Luckily the class of problems for which ECLiPSe is designed have a finite
set of decision variables each of which admits only finitely many
alternatives. Consequently it is only necessary to support a
restricted form of logic
which is easier to understand and easier to implement.
The nearest thing ECLiPSe offers to universal quantification is iteration
over finite sets, as for example the goal applist(value,Countries)
in figure 
.
The restricted logic of ECLiPSe has a benefit that the mapping from the conceptual model of the problem to the design model is an extension of the conceptual model rather than a rewriting. This means that when problem requirements change it is natural to capture this change in the conceptual model, and then carry them through to the design model. The result is that during application development the conceptual model and the design model remain in step. This avoids many of the pitfalls which await developers working on applications whose specifications are changing even during application development!