ISSUE-70 (CoreSafe): Should CORE be decideable [Core]

ISSUE-70 (CoreSafe): Should CORE be decideable [Core]

Raised by: Dave Reynolds
On product: Core

Should CORE have some form of safety constraint?

** Why might we want a safety criterion?

If it eases implementation so increasing the number of systems that can be fully conformant with CORE and so inter-operate via it.

For example, some existing systems perform a safety check and so could not implement a CORE that permitted more general rules. 
A concrete example of this is DLV, as discussed in:

Which classes of potentially unsafe rules can in fact be executed depends upon execution strategy so that permitting such rules may exclude some execution strategies and again limit interchange. See examples are given by Axel in the above email.

** Why might we not want this?

If the safety check itself is hard for developers to understand and implement it may limit up-take. 

If the safety criteria are conservative they may exclude rule sets which are of practical interest for interchange. For example:
   s(?x) :- s(?y), add(?y, 1, ?x), ?x < 10. 
has a finite set of ground entailments implementable by both PRD and BLD systems but fails at least some of the proposed strict safety criteria.

** Solution approaches mentioned so far:

(a) Yes. Define a strict safety criteria such as domain-safety as suggested by Jos in:

(b) Yes. Restrict use of builtins to non-recursive safe bindings as proposed by Axel in:

(c) No safety constraint.  But limit the conformance requirement. For example define conformance only over ground entailments of rulesets for which that is finite. 

(d) No safety constraint, no conformance limitation.

Received on Wednesday, 20 August 2008 17:24:49 UTC