Giters

triska / clpz

Constraint Logic Programming over Integers

Home Page:https://www.metalevel.at/prolog/clpz

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Compatibility with SWI

wouterbeek opened this issue · comments

commented

If this cannot be done ATM because of missing libraries or open issues, then we can at least assemble a list of requirements SWI should meet in order to add compatibility in the future.

commented

The most serious technical shortcoming of SWI is described in SWI-Prolog/roadmap#14.

Other technical issues are:

  • incompatible term and goal expansion
  • incompatible must_be predicate for type checking.
commented

at least assemble a list of requirements SWI should meet in order to add compatibility in the future

Further items:

  • standard conformance. By giving up conformance in SWI7, comparisons with conforming Prolog systems like SICStus or GNU become much more difficult which as consequence means less coverage and that less bugs are identified.

  • stability. Take i3a#365: A*max(A,-2)#>1,A in-1..2,A=1.

  • 7.1.32-11-gd0a4fc0 false (correct)

  • 7.3.14-42-ga83e0df success

The original library(clpfd) in SWI was tested 100+ CPU-years under the assumption that the underlying implementation does not change. That assumption turned out to be very wrong. Extensive tests cannot be manually inspected (even fast computers need years to wade through them), the errors specified in the standard are thus extremely helpful to judge the situation automatically and sort out false positives.

commented

@UWN Why would porting clpz to SWI require ISO conformance? I understand that ISO conformance has certain benefits in itself, but I do not see the clpz-specific part there.

commented

Why would porting clpz to SWI require ISO conformance?

@wouterbeek A reliable porting procedure requires testing. And that's where ISO conformance comes into play (see above post) - in particular precise errors but also the abstract syntax. SWI's actual unification mechanism implementation below is far too idiosyncratic to be a sufficient condition for a successful port.

commented

Additional reasons are mentioned in #4.

Since you have also contributed to the web page, I hope you can eliminate some of these problems, ensuring that CLP(FD) is presented in the way it is intended. This was previously the case, but is no longer the case with the new web page.

commented

any progress on this issue since 2017?