New chapter in cut opaqueness. It has rather to do with inlining
of disjunction and if-then-else, and whetherwe can also inline
negation as failure (\+)/1 and once so easily.

Now I am facing this test case:

p(a).
p(b).
q(b).
test(X,Y,Z) :- \+ (X,Y,Z).

GNU Prolog gives me:

/* GNU Prolog 1.5.0 */
?- \+((p(X),!,q(X))).
yes
?- test(p(X),!,q(X)).
yes

SWI-Prolog gives me:

/* SWI Prolog 9.1.17 */
?- \+((p(X),!,q(X))).
true.
?- test(p(X),!,q(X)).
false.

Interesting find, Ciao Prolog shows a warning, with a small
hickup, since the warning is shown twice:

/* Ciao Prolog 1.22.0 */
?- \+((p(X),!,q(X))).
WARNING: ! illegal in \+ or if-parts of ->, if; ignored
WARNING: ! illegal in \+ or if-parts of ->, if; ignored
no

?- test(p(X),!,q(X)).
false.

Otherwise it has the same bug. Meaning the warning is a little
bit useless, since it alllows me to do test/3. I was rather expecting
that a Prolog system that can issue a warning is aware of the

subleties to inline (\+)/1 and can correctly compile it. Further I don't
think according to ISO core standard a cut is disallowed in the if-part
of ->, as the warning suggests. It only needs a little more effort

to handle since the if-part of -> opens a new cut scope.

Mild Shock schrieb am Montag, 30. Oktober 2023 um 01:49:43 UTC+1:
> New chapter in cut opaqueness. It has rather to do with inlining
> of disjunction and if-then-else, and whetherwe can also inline
> negation as failure (\+)/1 and once so easily.
>
> Now I am facing this test case:
>
> p(a).
> p(b).
> q(b).
> test(X,Y,Z) :- \+ (X,Y,Z).
>
> GNU Prolog gives me:
>
> /* GNU Prolog 1.5.0 */
> ?- \+((p(X),!,q(X))).
> yes
> ?- test(p(X),!,q(X)).
> yes
>
> SWI-Prolog gives me:
>
> /* SWI Prolog 9.1.17 */
> ?- \+((p(X),!,q(X))).
> true.
> ?- test(p(X),!,q(X)).
> false.

If I use negation/1 the bug goes away:

p(a).
p(b).
q(b).
negation(X) :- X, !, fail.
negation(_).
test(X,Y,Z) :- negation((X,Y,Z)).

Now Trealla Prolog and SWI-Prolog also,
behaves consistently:

/* Trealla Prolog v2.29.42 */
?- negation((p(X),!,q(X))).
true.
?- test(p(X),!,q(X)).
true.

But the test case works fine in formerly Jekejeke Prolog:

/* Jekejeke Prolog 1.6.4 */
?- \+((p(X),!,q(X))).
true.
?- test(p(X),!,q(X)).
true.

And also in my Dogelog Player for JavaScript, Python and Java:

/* Dogelog Player 1.1.3 */
?- \+((p(X),!,q(X))).
true.
?- test(p(X),!,q(X)).
true.

The Java version is new, but the 3 Amigos behave exactly the same.

Mild Shock schrieb am Dienstag, 31. Oktober 2023 um 02:29:31 UTC+1:
> If I use negation/1 the bug goes away:
>
> p(a).
> p(b).
> q(b).
> negation(X) :- X, !, fail.
> negation(_).
> test(X,Y,Z) :- negation((X,Y,Z)).
>
> Now Trealla Prolog and SWI-Prolog also,
> behaves consistently:
>
> /* Trealla Prolog v2.29.42 */
> ?- negation((p(X),!,q(X))).
> true.
> ?- test(p(X),!,q(X)).
> true.

A big Prolog system, that doesn’t consider (\+)/2 a control construct with
body conversion, unlike SWI-Prolog, is the XSB Prolog system. I get this
result, twice success, moving out a subterm doesn’t change anything:

/* XSB Version 5.0-beta */
?- \+((p(X),!,q(X))).
X = _h387
yes

?- Y=!, \+((p(X),Y,q(X))).
Y = !
X = _h465

Was using May 15, 2022 version of XSB. Don’t know whether
there are other versions that would behave differently. No wonder,
XSB is also a Prolog system that champions user defined predicate

inlining in certain circumstance, if I am not mistaken.

Mild Shock schrieb am Dienstag, 31. Oktober 2023 um 02:35:53 UTC+1:
> But the test case works fine in formerly Jekejeke Prolog:
>
> /* Jekejeke Prolog 1.6.4 */
> ?- \+((p(X),!,q(X))).
> true.
> ?- test(p(X),!,q(X)).
> true.
>
> And also in my Dogelog Player for JavaScript, Python and Java:
>
> /* Dogelog Player 1.1.3 */
> ?- \+((p(X),!,q(X))).
> true.
> ?- test(p(X),!,q(X)).
> true.
>
> The Java version is new, but the 3 Amigos behave exactly the same.
> Mild Shock schrieb am Dienstag, 31. Oktober 2023 um 02:29:31 UTC+1:
> > If I use negation/1 the bug goes away:
> >
> > p(a).
> > p(b).
> > q(b).
> > negation(X) :- X, !, fail.
> > negation(_).
> > test(X,Y,Z) :- negation((X,Y,Z)).
> >
> > Now Trealla Prolog and SWI-Prolog also,
> > behaves consistently:
> >
> > /* Trealla Prolog v2.29.42 */
> > ?- negation((p(X),!,q(X))).
> > true.
> > ?- test(p(X),!,q(X)).
> > true.

But was only testing the top-level, not sure what spooky
skeletons there are, in XSB dark alleys. Like when using
consult and/or compiler. It all belongs to this topic:

Ahead-of-time compilation
https://en.wikipedia.org/wiki/Ahead-of-time_compilation

Mild Shock schrieb am Donnerstag, 2. November 2023 um 18:09:00 UTC+1:
> A big Prolog system, that doesn’t consider (\+)/2 a control construct with
> body conversion, unlike SWI-Prolog, is the XSB Prolog system. I get this
> result, twice success, moving out a subterm doesn’t change anything:
>
> /* XSB Version 5.0-beta */
> ?- \+((p(X),!,q(X))).
> X = _h387
> yes
>
> ?- Y=!, \+((p(X),Y,q(X))).
> Y = !
> X = _h465
>
> Was using May 15, 2022 version of XSB. Don’t know whether
> there are other versions that would behave differently. No wonder,
> XSB is also a Prolog system that champions user defined predicate
>
> inlining in certain circumstance, if I am not mistaken.
> Mild Shock schrieb am Dienstag, 31. Oktober 2023 um 02:35:53 UTC+1:
> > But the test case works fine in formerly Jekejeke Prolog:
> >
> > /* Jekejeke Prolog 1.6.4 */
> > ?- \+((p(X),!,q(X))).
> > true.
> > ?- test(p(X),!,q(X)).
> > true.
> >
> > And also in my Dogelog Player for JavaScript, Python and Java:
> >
> > /* Dogelog Player 1.1.3 */
> > ?- \+((p(X),!,q(X))).
> > true.
> > ?- test(p(X),!,q(X)).
> > true.
> >
> > The Java version is new, but the 3 Amigos behave exactly the same.
> > Mild Shock schrieb am Dienstag, 31. Oktober 2023 um 02:29:31 UTC+1:
> > > If I use negation/1 the bug goes away:
> > >
> > > p(a).
> > > p(b).
> > > q(b).
> > > negation(X) :- X, !, fail.
> > > negation(_).
> > > test(X,Y,Z) :- negation((X,Y,Z)).
> > >
> > > Now Trealla Prolog and SWI-Prolog also,
> > > behaves consistently:
> > >
> > > /* Trealla Prolog v2.29.42 */
> > > ?- negation((p(X),!,q(X))).
> > > true.
> > > ?- test(p(X),!,q(X)).
> > > true.

What can we say to the Prolog systems developers out there?

********************************************************
Don't worry your headache will soon
go away, and replaced by a full migraine.
********************************************************

Just joking, my suspicions, its not that grave. Ideas popping up.

Disclaimer: I only found this book today through google search of
“memberchk”. It also explains the difference between (\+)/1 and not/1.
At least for the Prolog system they were dealing with:

Computing with logic - 1988
https://archive.org/details/computingwithlog0000maie/page/322/mode/2up

So the bootstrapping would be maybe rather:

not(X) :- must_be(ground, X), \+ X.

Or NU-Prolog style with some freeze as well. The idea back then
was that ground argument to (\+)/1 is “safe”, has the desired semantics
of a logical negation. Meanwhile I guess it penetrated that variants

with non-ground arguments to (\+)/1 can also receive some declarative
reading using the idea of an existential quantifier. But the unsafe aspect
is still, how do we know what quantifier is intended and realized?

If I am not mistaken some of this idea of not/1 still survives in XSB tabling
not, and made it back into SWI-Prologs tnot/1. Not 100% sure. SWI-Prologs
tnot/1 does a delay and can elicit missing model or ambigious model.

Mild Shock schrieb am Donnerstag, 2. November 2023 um 18:48:01 UTC+1:
> What can we say to the Prolog systems developers out there?
>
> ********************************************************
> Don't worry your headache will soon
> go away, and replaced by a full migraine.
> ********************************************************
>
> Just joking, my suspicions, its not that grave. Ideas popping up.

Concerning XSB , I guess was expecting too much good.
It has the same bug when consulting the test case:

q1 :- \+((p(X),!,q(X))).
q2 :- Y=!, \+((p(X),Y,q(X))).

?- q1.
yes
?- q2.
no

Mild Shock schrieb am Donnerstag, 2. November 2023 um 22:04:34 UTC+1:
> Disclaimer: I only found this book today through google search of
> “memberchk”. It also explains the difference between (\+)/1 and not/1.
> At least for the Prolog system they were dealing with:
>
> Computing with logic - 1988
> https://archive.org/details/computingwithlog0000maie/page/322/mode/2up
>
> So the bootstrapping would be maybe rather:
>
> not(X) :- must_be(ground, X), \+ X.
>
> Or NU-Prolog style with some freeze as well. The idea back then
> was that ground argument to (\+)/1 is “safe”, has the desired semantics
> of a logical negation. Meanwhile I guess it penetrated that variants
>
> with non-ground arguments to (\+)/1 can also receive some declarative
> reading using the idea of an existential quantifier. But the unsafe aspect
> is still, how do we know what quantifier is intended and realized?
>
> If I am not mistaken some of this idea of not/1 still survives in XSB tabling
> not, and made it back into SWI-Prologs tnot/1. Not 100% sure. SWI-Prologs
> tnot/1 does a delay and can elicit missing model or ambigious model.
> Mild Shock schrieb am Donnerstag, 2. November 2023 um 18:48:01 UTC+1:
> > What can we say to the Prolog systems developers out there?
> >
> > ********************************************************
> > Don't worry your headache will soon
> > go away, and replaced by a full migraine.
> > ********************************************************
> >
> > Just joking, my suspicions, its not that grave. Ideas popping up.

On Friday, 3 November 2023 at 12:32:07 UTC+1, Mild Shock wrote:
> Concerning XSB , I guess was expecting too much good.
> It has the same bug when consulting the test case:
>
> > p(a).
> > p(b).
> > q(b).
> q1 :- \+((p(X),!,q(X))).
> q2 :- Y=!, \+((p(X),Y,q(X))).
>
> ?- q1.
> yes
> ?- q2.
> no

The "bug" in that case is more generally the fact that Y translates
to call(Y), which I guess you are "supposed to know", and which I
cannot say if it's standard since our standard is behind a paywall
(and I have lost my copy and I won't buy it again since I'd be rather
working on a better Prolog than the ISO, too many fundamental
issues), but is certainly all over the place...

Julio

In my opinion the GNU Result is Ok and according
to the ISO core standard, since (\+)/1 is not included
in the list of control constructs that are subject

to body conversion, i.e. call/1 wrapping:

/* GNU Prolog 1.5.0 */
p(a).
p(b).
q(b).
q1 :- \+((p(X),!,q(X))).
q2 :- Y=!, \+((p(X),Y,q(X))).

?- q1.
yes
?- q2.
yes

You have just to lookup section 7.6 of the ISO core
standard to see that (\+)/1 has no part in the
call/1 wrapping. But it seems that Prolog systems

do not all implement section 7.6 this way, the
way it was specified. A further problem is that some
Prolog system sometimes implement section 7.6 correctly,

and sometimes implement section 7.6 wrong. For example
without a dynamic directive XSB does it wrong,
thats what is seen in your quote. But if you add

a dynamic/1 directive, it turns out to be like this:

/* XSB Version 5.0-beta */
p(a).
p(b).
q(b).
:- dynamic q1/0.
q1 :- \+((p(X),!,q(X))).
:- dynamic q2/0.
q2 :- Y=!, \+((p(X),Y,q(X))).

?- q1.
yes
?- q2.
yes

Now with dynamic directive XSB and GNU agree. Without
dynamic directive XSB and GNU disagree.

Julio Di Egidio schrieb:
> On Friday, 3 November 2023 at 12:32:07 UTC+1, Mild Shock wrote:
>> Concerning XSB , I guess was expecting too much good.
>> It has the same bug when consulting the test case:
>>
>>> p(a).
>>> p(b).
>>> q(b).
>> q1 :- \+((p(X),!,q(X))).
>> q2 :- Y=!, \+((p(X),Y,q(X))).
>>
>> ?- q1.
>> yes
>> ?- q2.
>> no
>
> The "bug" in that case is more generally the fact that Y translates
> to call(Y), which I guess you are "supposed to know", and which I
> cannot say if it's standard since our standard is behind a paywall
> (and I have lost my copy and I won't buy it again since I'd be rather
> working on a better Prolog than the ISO, too many fundamental
> issues), but is certainly all over the place...
>
> Julio
>

So its not an ISO core standard problem. Its
a bug introduced by Prolog system implementors
in the area of ahead-of-time compilation:

Ahead-of-time compilation
https://en.wikipedia.org/wiki/Ahead-of-time_compilation

Mostlikely XSB does compile static clauses more
strongly than dynamic clauses, but it does so
by an incorrect compilation method.

So its an implementation bug not some specification
flaw. But its hard to fix this implementatin bug.
So far was experimenting with this rather trivial

guard, to check whether I am allowed to rewrite
(\+ A) into (A -> fail; true):

sys_trans_allowed(V) :- var(V), !, fail.
sys_trans_allowed((A,B)) :- sys_trans_allowed(A), sys_trans_allowed(B).
sys_trans_allowed((A;B)) :- sys_trans_allowed(A), sys_trans_allowed(B).
sys_trans_allowed((A->B)) :- sys_trans_allowed(A), sys_trans_allowed(B).
sys_trans_allowed(A) :- callable(A).

But I am not 100% happy with such a check, maybe
there is a more linear compilation technique.

Mild Shock schrieb:
>
> In my opinion the GNU Result is Ok and according
> to the ISO core standard, since (\+)/1 is not included
> in the list of control constructs that are subject
>
> to body conversion, i.e. call/1 wrapping:
>
> /* GNU Prolog 1.5.0 */
> p(a).
> p(b).
> q(b).
> q1 :- \+((p(X),!,q(X))).
> q2 :- Y=!, \+((p(X),Y,q(X))).
>
> ?- q1.
> yes
> ?- q2.
> yes
>
> You have just to lookup section 7.6 of the ISO core
> standard to see that (\+)/1 has no part in the
> call/1 wrapping. But it seems that Prolog systems
>
> do not all implement section 7.6 this way, the
> way it was specified. A further problem is that some
> Prolog system sometimes implement section 7.6 correctly,
>
> and sometimes implement section 7.6 wrong. For example
> without a dynamic directive XSB does it wrong,
> thats what is seen in your quote. But if you add
>
> a dynamic/1 directive, it turns out to be like this:
>
> /* XSB Version 5.0-beta */
> p(a).
> p(b).
> q(b).
> :- dynamic q1/0.
> q1 :- \+((p(X),!,q(X))).
> :- dynamic q2/0.
> q2 :- Y=!, \+((p(X),Y,q(X))).
>
> ?- q1.
> yes
> ?- q2.
> yes
>
> Now with dynamic directive XSB and GNU agree. Without
> dynamic directive XSB and GNU disagree.
>
> Julio Di Egidio schrieb:
>> On Friday, 3 November 2023 at 12:32:07 UTC+1, Mild Shock wrote:
>>> Concerning XSB , I guess was expecting too much good.
>>> It has the same bug when consulting the test case:
>>>
>>>> p(a).
>>>> p(b).
>>>> q(b).
>>> q1 :- \+((p(X),!,q(X))).
>>> q2 :- Y=!, \+((p(X),Y,q(X))).
>>>
>>> ?- q1.
>>> yes
>>> ?- q2.
>>> no
>>
>> The "bug" in that case is more generally the fact that Y translates
>> to call(Y), which I guess you are "supposed to know", and which I
>> cannot say if it's standard since our standard is behind a paywall
>> (and I have lost my copy and I won't buy it again since I'd be rather
>> working on a better Prolog than the ISO, too many fundamental
>> issues), but is certainly all over the place...
>>
>> Julio
>>
>

On Saturday, 4 November 2023 at 02:52:03 UTC+1, Mild Shock wrote:

> ?- q1.
> yes
> ?- q2.
> yes
>
> You have just to lookup section 7.6 of the ISO core

Which I have explained I have no access to.
OTOH you completely miss the point which has
nothing to do with body conversion in '\+', that
just calling 'Y' is a short-hand, whether ISO or
not you have not told, for 'call(Y)', which is the
right way to write that code in Prolog and what
that code is in fact translated to in systems
where that short-hand is supported (most of
them probably): and since 'call' per se *is*
opaque to cuts (it does make cut scope)...
the code that is wrong is actually the one
you are calling right.

Julio

On Saturday, 4 November 2023 at 05:08:09 UTC+1, Julio Di Egidio wrote:

> the code that is wrong is actually the one
> you are calling right.

I mean the result, not the code.

There is no call/1 in q1 or q2, you
can use listing/1 in recent GNU Prolog:

/* GNU-Prolog 1.5.0, ISO conforming */
q2 :-
A = !,
\+ (p(B), A, q(B)).

This is in conformity with section 7.6 of
the ISO core standard, which doesn't
say that call/1 is placed inside (\+)/1

at compile time. listing/1 usually shows
call/1 where one was instered at compile time,
but it doesn't show one. Where do you get the

idea from that there is a call/1 around Y?
This happens erroreously in SWI-Prolog
in violation of section 7.6 of the ISO core standard:

/* SWI-Prolog 9.1.17, Not ISO conforming */
?- listing(q2).
q2 :-
A=!,
\+ ( p(B),
call(A),
q(B)
).

Julio Di Egidio schrieb:
> On Saturday, 4 November 2023 at 02:52:03 UTC+1, Mild Shock wrote:
>
>> ?- q1.
>> yes
>> ?- q2.
>> yes
>>
>> You have just to lookup section 7.6 of the ISO core
>
> Which I have explained I have no access to.
> OTOH you completely miss the point which has
> nothing to do with body conversion in '\+', that
> just calling 'Y' is a short-hand, whether ISO or
> not you have not told, for 'call(Y)', which is the
> right way to write that code in Prolog and what
> that code is in fact translated to in systems
> where that short-hand is supported (most of
> them probably): and since 'call' per se *is*
> opaque to cuts (it does make cut scope)...
> the code that is wrong is actually the one
> you are calling right.
>
> Julio
>

There is no call/1 in q1 or q2, you
can use listing/1 in recent GNU Prolog:

/* GNU-Prolog 1.5.0, ISO conforming */
?- listing(q2).
q2 :-
A = !,
\+ (p(B), A, q(B)).

This is in conformity with section 7.6 of
the ISO core standard, which doesn't
say that call/1 is placed inside (\+)/1

at compile time. listing/1 usually shows
call/1 where one was instered at compile time,
but it doesn't show one. Where do you get the

idea from that there is a call/1 around Y?
This happens erroreously in SWI-Prolog
in violation of section 7.6 of the ISO core standard:

/* SWI-Prolog 9.1.17, Not ISO conforming */
?- listing(q2).
q2 :-
A=!,
\+ ( p(B),
call(A),
q(B)
).

Julio Di Egidio schrieb:
> On Saturday, 4 November 2023 at 02:52:03 UTC+1, Mild Shock wrote:
>
>> ?- q1.
>> yes
>> ?- q2.
>> yes
>>
>> You have just to lookup section 7.6 of the ISO core
>
> Which I have explained I have no access to.
> OTOH you completely miss the point which has
> nothing to do with body conversion in '\+', that
> just calling 'Y' is a short-hand, whether ISO or
> not you have not told, for 'call(Y)', which is the
> right way to write that code in Prolog and what
> that code is in fact translated to in systems
> where that short-hand is supported (most of
> them probably): and since 'call' per se *is*
> opaque to cuts (it does make cut scope)...
> the code that is wrong is actually the one
> you are calling right.
>
> Julio
>

You can also use vm_list/1 in SWI-Prolog to
see the offending instruction:

?- vm_list(q2).
========================================================================
q2/0
========================================================================
0 s_virgin
1 i_exit
----------------------------------------
clause 1 (<clause>(000001dff79f6040)):
----------------------------------------
0 i_enter
1 b_unify_fc(0,!)
4 c_not(2,'L1')
7 b_firstvar(1)
9 i_call(user:p/1)
11 b_var0
12 i_usercall0
13 b_var1
14 i_call(user:q/1)
16 c_cut(2)
18 c_fail
19 c_jmp('L2')
L1: 21 c_var(1)
L2: 23 i_exit
true.

The offending instruction is:

11 b_var0
12 i_usercall0

But I don’t have yet an alternative proposal,
except for a sys_trans_allowed/1 check, which
would make a compilation decision, and then refuse to

inline. But a solution where it is nevertheless
inlined, I haven’t worked out one yet. If i_usercall0
is repaced by something too expensive, things also

don’t workout very well. Obviously an alternative
to i_usercall0 is needed, that is cut transparent
among other things.

Mild Shock schrieb:
> There is no call/1 in q1 or q2, you
> can use listing/1 in recent GNU Prolog:
>
> /* GNU-Prolog 1.5.0, ISO conforming */
> ?- listing(q2).
> q2 :-
>     A = !,
>     \+ (p(B), A, q(B)).
>
> This is in conformity with section 7.6 of
> the ISO core standard, which doesn't
> say that call/1 is placed inside (\+)/1
>
> at compile time. listing/1 usually shows
> call/1 where one was instered at compile time,
> but it doesn't show one. Where do you get the
>
> idea from that there is a call/1 around Y?
> This happens erroreously in SWI-Prolog
> in violation of section 7.6 of the ISO core standard:
>
> /* SWI-Prolog 9.1.17, Not ISO conforming */
> ?- listing(q2).
> q2 :-
>     A=!,
>     \+ ( p(B),
>          call(A),
>          q(B)
>        ).
>
> Julio Di Egidio schrieb:
>> On Saturday, 4 November 2023 at 02:52:03 UTC+1, Mild Shock wrote:
>>
>>> ?- q1.
>>> yes
>>> ?- q2.
>>> yes
>>>
>>> You have just to lookup section 7.6 of the ISO core
>>
>> Which I have explained I have no access to.
>> OTOH you completely miss the point which has
>> nothing to do with body conversion in '\+', that
>> just calling 'Y' is a short-hand, whether ISO or
>> not you have not told, for 'call(Y)', which is the
>> right way to write that code in Prolog and what
>> that code is in fact translated to in systems
>> where that short-hand is supported (most of
>> them probably): and since 'call' per se *is*
>> opaque to cuts (it does make cut scope)...
>> the code that is wrong is actually the one
>> you are calling right.
>>
>> Julio
>>
>

On Saturday, 4 November 2023 at 18:12:13 UTC+1, Mild Shock wrote:

> There is no call/1 in q1 or q2, you
> can use listing/1 in recent GNU Prolog:

LOL, you are a joke: which is exactly the reason why, for a
correct definition of correct Prolog code, it *fails* your test.

Whether that is ISO or not I'll leave those interested to find out.

Have fun.

Julio

Deniel of a bug?
Creating a smoke screen?
How low can one get?

LoL

Julio Di Egidio schrieb am Samstag, 4. November 2023 um 20:43:01 UTC+1:
> On Saturday, 4 November 2023 at 18:12:13 UTC+1, Mild Shock wrote:
>
> > There is no call/1 in q1 or q2, you
> > can use listing/1 in recent GNU Prolog:
> LOL, you are a joke: which is exactly the reason why, for a
> correct definition of correct Prolog code, it *fails* your test.
>
> Whether that is ISO or not I'll leave those interested to find out.
>
> Have fun.
>
> Julio

Denial of a bug?
Creating a smoke screen?
How low can one get?

LoL

Julio Di Egidio schrieb am Samstag, 4. November 2023 um 20:43:01 UTC+1:
> On Saturday, 4 November 2023 at 18:12:13 UTC+1, Mild Shock wrote:
>
> > There is no call/1 in q1 or q2, you
> > can use listing/1 in recent GNU Prolog:
> LOL, you are a joke: which is exactly the reason why, for a
> correct definition of correct Prolog code, it *fails* your test.
>
> Whether that is ISO or not I'll leave those interested to find out.
>
> Have fun.
>
> Julio

Actually a test case is quite rare in ISO Prolog. There is no
explicit test case for (\+)/1 that tests the matter. But a related
one for call/1, which can be adapted to also test (\+)/1:

Take these two facts:

a(1).
a(2).

Now perform these tests, the test case has also a nice
explanation in the ISO core standard itself:

/* ISO 7.8.3.4, ISO 7 */
?- Z = !, call( (Z=!, a(X), Z) ).
Z = !,
X = 1.

/* ISO 7.8.3.4, ISO 8 */
?- call( (Z=!, a(X), Z) ).
Z = !,
X = 1 ;
Z = !,
X = 2.

So sometimes Z gets wrapped into call(Z) and sometimes
not. Can you explain what happens Culio?

Mild Shock schrieb am Sonntag, 5. November 2023 um 20:38:54 UTC+1:
> Denial of a bug?
> Creating a smoke screen?
> How low can one get?
>
> LoL
> Julio Di Egidio schrieb am Samstag, 4. November 2023 um 20:43:01 UTC+1:
> > On Saturday, 4 November 2023 at 18:12:13 UTC+1, Mild Shock wrote:
> >
> > > There is no call/1 in q1 or q2, you
> > > can use listing/1 in recent GNU Prolog:
> > LOL, you are a joke: which is exactly the reason why, for a
> > correct definition of correct Prolog code, it *fails* your test.
> >
> > Whether that is ISO or not I'll leave those interested to find out.
> >
> > Have fun.
> >
> > Julio

Here is an adaption to negation, basically my testcase.
Add a further fact as follows:

b(2).

The test case is now:

/* GNU Prolog 1.5.0, does it correctly */
/* ISO 7.8.3.4, ISO 7 adapted */
?- Z = !, \+( (Z=!, a(X), Z, b(X)) ).
Z = !
/* ISO 7.8.3.4, ISO 8 adapted */
?- \+( (Z=!, a(X), Z, b(X)) ).
no

/* SWI-Prolog 9.1.17, has the same bug */
/* ISO 7.8.3.4, ISO 7 adapted */
?- Z = !, \+( (Z=!, a(X), Z, b(X)) ).
false.
/* ISO 7.8.3.4, ISO 8 adapted */
?- \+( (Z=!, a(X), Z, b(X)) ).
false.

SWI-Prolog says thice false which is wrong,
the frist test case derived from ISO 7.8.3.4, ISO 7
should say yes or Z = !.

Mild Shock schrieb am Sonntag, 5. November 2023 um 21:02:31 UTC+1:
> Actually a test case is quite rare in ISO Prolog. There is no
> explicit test case for (\+)/1 that tests the matter. But a related
> one for call/1, which can be adapted to also test (\+)/1:
>
> Take these two facts:
>
> a(1).
> a(2).
>
> Now perform these tests, the test case has also a nice
> explanation in the ISO core standard itself:
>
> /* ISO 7.8.3.4, ISO 7 */
> ?- Z = !, call( (Z=!, a(X), Z) ).
> Z = !,
> X = 1.
>
> /* ISO 7.8.3.4, ISO 8 */
> ?- call( (Z=!, a(X), Z) ).
> Z = !,
> X = 1 ;
> Z = !,
> X = 2.
>
> So sometimes Z gets wrapped into call(Z) and sometimes
> not. Can you explain what happens Culio?
> Mild Shock schrieb am Sonntag, 5. November 2023 um 20:38:54 UTC+1:
> > Denial of a bug?
> > Creating a smoke screen?
> > How low can one get?
> >
> > LoL
> > Julio Di Egidio schrieb am Samstag, 4. November 2023 um 20:43:01 UTC+1:
> > > On Saturday, 4 November 2023 at 18:12:13 UTC+1, Mild Shock wrote:
> > >
> > > > There is no call/1 in q1 or q2, you
> > > > can use listing/1 in recent GNU Prolog:
> > > LOL, you are a joke: which is exactly the reason why, for a
> > > correct definition of correct Prolog code, it *fails* your test.
> > >
> > > Whether that is ISO or not I'll leave those interested to find out.
> > >
> > > Have fun.
> > >
> > > Julio

On Sunday, 5 November 2023 at 21:02:31 UTC+1, Mild Shock wrote:

> Actually a test case is quite rare in ISO Prolog.

LOL. Test cases are the *only* thing available around here!!

> There is no explicit test case for (\+)/1 that tests the matter.

Nor \+ has anything to do with this matter.

> Take these two facts:
>
> a(1).
> a(2).
>
> Now perform these tests,

> /* ISO 7.8.3.4, ISO 7 */
> ?- Z = !, call( (Z=!, a(X), Z) ).
> Z = !,
> X = 1.

Where Z does *not* become call(Z).

> /* ISO 7.8.3.4, ISO 8 */
> ?- call( (Z=!, a(X), Z) ).
> Z = !,
> X = 1 ;
> Z = !,
> X = 2.
>
> So sometimes Z gets wrapped into call(Z)
> and sometimes not.

Apparently.

> Can you explain what happens Culio?

Thanks for that, Burp. I can't. Can you?

Julio

On Sunday, 5 November 2023 at 21:14:49 UTC+1, Julio Di Egidio wrote:
> On Sunday, 5 November 2023 at 21:02:31 UTC+1, Mild Shock wrote:
>
> > Actually a test case is quite rare in ISO Prolog.
> LOL. Test cases are the *only* thing available around here!!
> > There is no explicit test case for (\+)/1 that tests the matter.
> Nor \+ has anything to do with this matter.
> > Take these two facts:
> >
> > a(1).
> > a(2).
> >
> > Now perform these tests,
> > /* ISO 7.8.3.4, ISO 7 */
> > ?- Z = !, call( (Z=!, a(X), Z) ).
> > Z = !,
> > X = 1.
> Where Z does *not* become call(Z).
> > /* ISO 7.8.3.4, ISO 8 */
> > ?- call( (Z=!, a(X), Z) ).
> > Z = !,
> > X = 1 ;
> > Z = !,
> > X = 2.
> >
> > So sometimes Z gets wrapped into call(Z)
> > and sometimes not.
>
> Apparently.
>
> > Can you explain what happens Culio?
>
> Thanks for that, Burp. I can't. Can you?

P.S. Which is why the best practice is to just
never write a nude call to a variable...

Julio

On Sunday, 5 November 2023 at 21:18:53 UTC+1, Julio Di Egidio wrote:
> On Sunday, 5 November 2023 at 21:14:49 UTC+1, Julio Di Egidio wrote:
> > On Sunday, 5 November 2023 at 21:02:31 UTC+1, Mild Shock wrote:
> >
> > > Actually a test case is quite rare in ISO Prolog.
> > LOL. Test cases are the *only* thing available around here!!
> > > There is no explicit test case for (\+)/1 that tests the matter.
> > Nor \+ has anything to do with this matter.
> > > Take these two facts:
> > >
> > > a(1).
> > > a(2).
> > >
> > > Now perform these tests,
> > > /* ISO 7.8.3.4, ISO 7 */
> > > ?- Z = !, call( (Z=!, a(X), Z) ).
> > > Z = !,
> > > X = 1.
> > Where Z does *not* become call(Z).
> > > /* ISO 7.8.3.4, ISO 8 */
> > > ?- call( (Z=!, a(X), Z) ).
> > > Z = !,
> > > X = 1 ;
> > > Z = !,
> > > X = 2.
> > >
> > > So sometimes Z gets wrapped into call(Z)
> > > and sometimes not.
> >
> > Apparently.
> >
> > > Can you explain what happens Culio?
> >
> > Thanks for that, Burp. I can't. Can you?
> P.S. Which is why the best practice is to just
> never write a nude call to a variable...

P.P.S. Assuming at least that much is consistent, which,
given the above, I am not even very much confident into...

Enough said. Cheers.

Julio