A number of answer set solvers have been proposed in recent years, such as
, DLV, Cmodels, and ASSAT. Most existing ASP solvers have been extended to provide front-ends that are suitable to encode specialized forms of knowledge-e.g., weight-constraints, restricted forms of optimization, front-ends for planning and diagnosis. These features allow declarative solutions in speci.c application domains. However, this is not completely satisfactory:
– The development of an ASP program is viewed as a “monolithic” process. Most ASP systems offer only a batch approach to execution of programs-programs are completely developed, “compiled”, executed, and finally answer sets are proposed to the user. The process lacks any levels of interaction with the user. In particular, it does not directly support an interactive development of programs (as in Prolog), where one can immediately explore the results of simply adding/removing rules.
– ASP programmers can control the computation of answer sets through the rules that they include in the logic program. Nevertheless, ASP systems offer very limited capabilities for reasoning on the
of answer sets associated to a program-e.g., to perform selection of models according to user-defined criteria or to compare models. These activities are important in many application domains-e.g., to express soft constraints, to support preferences when using ASP to perform planning.
– ASP solvers are independent systems; interaction with other languages can be performed only through complex, low level APIs; this prevents programmers from writing programs that manipulate ASP programs and answer sets as first-class citizens. E.g., we wish to write programs in a high-level language (Prolog in this case), which are capable to access ASP programs, modify their structure (by adding or removing rules), and access and reason with answer sets. This type of features is essential in many domains-e.g., automatically modify the plan length in a planning problem.