How to Use ACLP
Within ACLP, problems can be represented directly
from their declarative specification with the
ability to accommodate in the representation natural
structures or special features of the specific application,
which can often lead to better solutions.
A problem in ACLP is represented by an abductive theory consisting of
a triple < P, A, IC > where:
The constraint predicates that can be used in the body
of a program rule or an integrity constraint
can be (i) arithmetic constraint
predicates or (ii) logical contraint predicates .
The arithmetic constraint predicates that are
supported by the current ACLP implementation are:
The system also supports logical constraints such as conjunction,
#/\ , and disjunction, #\/ . These simple
constraints can be combined to build complex logical constraint
Handling of the ICs by the System
During a consistency phase for the consistent addition of
a new abducible assumption, a(X) where X is
now a "marked" ECLiPSe domain variable, constraints are automatically
negated and set in the current constraint store.
This negation of the constraints is the usual mathematical negation, e.g.
the negation of the aritmetic constraint T1\#< T2
The negation of the logical constraint #/\ is
the negation of the logical constraint T1##5 #/\ T2#>2 is
T1#=5 #\/ T2#<=2 .
Negation as Failure
Negation as failure is handled through abduction. The semantics of NAF
is that of partial stable models. Effectively, all occurences of
not(p) in the theory are replaced by not_p which is treated
as an abducible with the canonical integrity constraint
ic :- not_p, p. In the current implementation it is necessary
for the user to specify explicitly both the fact that not_p
is abducible by adding a statement abducible_predicate(not_p/arity)
in the program as well as adding the above canonical constraint in the
program. (Note if the definition of the predicate p depends
on abducibles then as mentioned above we need to unfold this in the
integrity constraints for these abducibles to appear explicitly in the
ACLP System Predicates
The system predicate test/1 can be used in program
to test the existence or not of an abducible in the set of the current
abducibles found so far. Its syntax is test(Abducible) .
One example taken from the job shop scheduling problem is the
T #> T1, T #< T2.
where the goal working(R,T1,T2) checks if there is any
job started till that point of execution on resource R
between the time points T1
and T2 . The start/3 is an abducible
predicate and has been defined as such by the declaration:
Computational Features of ACLP
As the computation of an ACLP goal evolves the system holds two
inter-related sets of information (i) the domain constraints
that have been set and (ii) the abducible hypothese that have
been assumed, up to the current point on the computation.
The first set is effectively managed by the underlying ECLiPSe system
whereas the second is managed explicitely by the ACLP system.
Every time a new domain constraint is set the system tests using the ECLiPSe
constraint handler if the new set of domain constraints is satisfiable.
When a new abducible hypothesis is made the ACLP system checks the
satisfaction of the integrity constraints in the user-defined abductive
theory of the problem at hand. This may require new domain
constraints or abductive hypothesis to be made.
The ACLP system adopts the following search quidelines to build its
In addition, in version 1 of the system whenever it is possible to use an
existing abductive hypothesis to satisfy a constraint then this can prohibit
the use of other ways (e.g. setting a domain constraint or generating a new
abductive hypothesis) to satisfy this integrity constraint.
As in CLP with ECLiPSe the order in which the integrity constraints are
checked as well as the order of the conditions of an integrity constraint
can sometimes affect significantly the computation of ACLP.
Back to ACLP home page