| OCR Text |
Show CHAPTER 5 CONSTRAINT REPRESENTATION. The constraint and constraint instance definitions in this section are based on the defini-tions in Gosling's Phd dissertation (4]. The constraint satisfaction algorithms used in the thesis are not those of Gosling, rather they are based on a depth first constraint search. The methods of Constraint Kernel satisfaction are applicable to other constraint representations and satisfaction algorithms but the work of Gosling and my depth first search algorithms are amenable to natural extensions in the Constraint Kernels. 5.1 Constraint Representation. A constraint is represented as a procedure. The constrained objects are passed in as parameters to the procedure. Constraints in [4] are composed of two parts: 1. The constraint relation. The relation is a boolean predicate which indicates whether or not the constraint is satisfied. 2. Firing clauses. If the constraint is not satisfied, the firing clauses give alternative sets of assignment statements, any of which will satisfy the constraint. The constraint relation is necessary only to determine if the constraint is satisfied. If a constraint with a constraint relation is fired when the constraint is in fact already satisfied, the constraint relation will be true and none of the firing clauses will be invoked. This is desirable behavior in a constraint system wHhout reusable constraint plans since H avoids work in the occasional case where the constraint systems thinks a constraint is unsatisfied when In fact the constraint is already satisfied. In a constraint system with reusable constraint plans, the constraint relation is unnecessary since the constraint must always fire, even if at some time the ~nstraint happens to be satisfied already. H the constraint fired in some cases and did not fire in other cases then the constraint satisfaction plan would not be rep·3atable or reusable. The Constraint Kernels' con- |
