Re: 5.7.X : problem with attributed variables and memberchk ?

On Sat, Oct 04, 2008 at 10:08:59PM +0200, Bart Demoen wrote:
> 
> > ?- A in 0..5, B in 6..7, memberchk(A, [B, C]).
> > false.
> > 
> > 
> > Shouldn't the last one return :
> > A = C,
> > C in 0..5,
> > B in 6..7.
> > 
> > ?
> 
> First a look at:
> 
>        ?- help(memberchk).
>        memberchk(?Elem, +List)
>            Equivalent to member/2, but leaves no choice point.
> 
> This is enough to answer your question: yes, you are correct about
> your expectation.
> 
> In fact, the implementation of pl_memberchk in pl-list.c cuts the
> choicepoint before executing woken goals. It is a bit tricky to get
> this correct (from within C), but currently it doesn't deliver what
> the manual promises I think. If memchk/2 is written in Prolog, you get
> what you expect.

I come back on this, I think it is is more complex than just
a pl_memberchk problem.

I tried with a real example from the running of my app and a
handmade definition of member and memberchk, and both have
problem. I think something wrong happens when unification is done
(maybe it has to do with the woken goals you are talking about, I
do know nothing about all of this :).

This is what I get :

?- _G656 in 19..135, _G1879 in 12..134, _G1228 in 19..133, _G3188 in 0..19, _G3189 in 0..9\/11..200,
_G3190 in 0..200,
	mymember(ass(start(_G3188, _G3189, 4, _G3190)), [ass(start(0, 1, 0, _G1228)), ass(start(0, 0, 4, _G656))]).
false.

and
?- _G656 in 19..135, _G1879 in 12..134, _G1228 in 19..133, _G3188 in 0..19, _G3189 in 0..9\/11..200,
_G3190 in 0..200,
	mymember(ass(start(_G3188, _G3189, 4, _G3190)), [ass(start(0, 0, 4, _G656))]).
_G656 = _G3190,
_G3188 = 0,
_G3189 = 0,
_G3190 in 19..135,
_G1879 in 12..134,
_G1228 in 19..133 ;
false.

With this definition for mymember :
mymember(Element, [Element| _]).
mymember(Element, [_| List]) :-
	mymember(Element, List).

Thanks you for your help,

Victor