Attributed variables

[notoria]

Hello @triska, I'm using this version of clpz which was extracted from Scryer with some changes.

I tried this query with Scryer:

?- X in 0..2, Y in 1..3, X = Y.
clpz_attr(no,no,no,from_to(n(1),n(3)),fd_props([],[],[]),queue(A,B,C,D))-clpz_attr(no,no,no,from_to(n(0),n(2)),fd_props([],[],[]),queue(E,F,G,H)).
   X = Y, clpz:(X in 1..2).
?-

And I expected portray_clause/2 to also report:

clpz_attr('.','.','.',from_to(n(1),n(2)),fd_props([],[],[]),queue(_A,_B,_C,_D))-clpz_attr(no,no,no,from_to(n(1),n(3)),fd_props([],[],[]),queue(_A,_B,_C,_D)).

Since it would be trigger for X and Y. Is this expected?

[triska]

Personally, I find it extremely hard to think about two different library versions, so here is initial feedback for the version that ships with Scryer Prolog:

The expected behaviour after this unification is indeed that verify_attributes/3 is invoked, and it suffices that it is invoked once. For that invocation of verify_attributes/3, we cannot tell whether X or Y will be the first argument (I see no reason for an implementation to make any promises in that regard), and also there is no reason for the engine to invoke the predicate more than once. The provided implementation of verify_attributes/3 forms the intersection of the domain of the two variables, and the concatenation of their propagator queues (for all 3 types of triggering events: instantiation ("grounding"), boundary changes, and any domain changes), and as remaining goal states that the triggered propagators must be worked off (do_queue).

Personally, I found that Scryer Prolog so far handled everything exactly as I would expect it, and in fact more "by the book" than SICStus Prolog in that Scryer completely adheres to what the SICStus documentation about verify_attributes/3 says. There was even a case where I had to apply a change to library(clpb) to make it work in Scryer, and as far as I remember the necessity of the change was in fact entailed by the SICStus documentation even though the library appeared to work in SICStus Prolog without the change. The change was triska/scryer-prolog@e185b62.

[notoria]

Thank you a lot, I have a better idea how it works.

Personally, I find it extremely hard to think about two different library versions, so here is initial feedback for the version that ships with Scryer Prolog:

Sorry, I will stick with the version that ships with Scryer.

It seems that the reason why verify_attributes/3 can be invoked once is due to module.

Would there be any issue if verify_attributes/3 is invoked more than once in clpz?

[triska]

One important posting that may also help to get the right mental model (I previously wrote: "module") about verify_attributes/3: https://stackoverflow.com/questions/64786512/extending-unification-sicstus-style

[triska]

... where I now see you already participated! Still, a useful reference!

[triska]

Also, thanks to your question, I now found a completely unexpected situation in Scryer Prolog, explained in mthom/scryer-prolog#2732.

These are very subtle and difficult issues, difficult to test, and where potential mistakes may arise only very, very rarely. I therefore recommend to first and foremost put everything we can into ensuring compatibility with SICStus Prolog. This is difficult enough, which we see alone from the fact that Scryer Prolog is one of the few Prolog systems that aims for full compatibility with SICStus in this respect, and also from issues like the posted one. Why aim for SICStus? Because we know it works, for many different kinds of constraint solvers, including CLP(Q) which no free Prolog system provides in a way that works correctly.