Information Technology Reference
In-Depth Information
Then we discussed a proposal how to integrate constraint programming fea-
tures into the language. In this regard we believe that the use of an underlying
language based on rst-order logic, such as
, rather than a conventional
imperative language, makes the integration of constraints more natural and con-
ceptually simpler.
We analyzed here a number of issues related to the proposed integration, such
as the use of constrained types and the unknowns, interaction between the pro-
gram and the constraint store, and the parameter passing mechanisms. Finally,
we presented some examples that illustrate the resulting style of programming.
In our future work we plan to extend the work carried out in [2] to the
language proposal here outlined. More specically, we envisage to
Alma-0
{ extend the executable, operational semantics based on the ASF+SDF Meta-
Environment of [12];
{ extend both the
;
{ implement a set of constraint solvers or provide an interface between the
language and existing constraint solvers.
Alma-0
compiler and its underlying abstract machine
AAA
The rst item can be dealt with by adding to the executable semantics of
Alma-0
given in [2] a few rules that formalize the interaction between the program
and the store stipulated in Subsection 4.3. These rules are parameterized by the
constraint solvers attached to the store.
Regarding the last item, we plan to develop a simple solver for constraints
over nite domains to be used for prototyping and testing purposes. We also
plan to exploit more powerful external solvers already available for subsequent
releases of the system.
As already mentioned in Section 4.3, we do not allow so-called ask operations
in the store. This is a deliberate design decision which allows us to keep the
language design simple and the underlying execution model easy to implement.
Nevertheless, in future versions of the language, we plan to investigate the
possibility of equipping the store with an entailment procedure. This procedure
should check whether an evaluated form of a constraint is logically implied (or
entailed ) by the store. Upon encounter of an ask constraint, the entailment
procedure would check whether the evaluated form is entailed by the store. If it
is the case, the constraint evaluates to TRUE . Otherwise the constraint evaluates
to FALSE . We would require that the entailment procedure returns correct results
but would not assume that it is complete.
We did not deal here with some of the issues related to the design of the
language. Specically, we omitted discussion of
{ a full set of built-ins, in particular the ones appropriate for constraint opti-
mization,
{ primitives for selecting variable and value selection strategies,
{ the language support for the dynamic creation of unknowns.
These can be taken care of in a systematic way and lead to a complete and
rigorous denition of an imperative constraint programming language.
 
Search WWH ::




Custom Search