From Newsgroup: comp.lang.prolog

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

I made the observation while looking at
debugger traces, choice point elimination,
driven by indexes, also determines what
FAIL/REDO ports a debugger shows.

What is amazing Scryer Prolog, which has
a tamer version of multi-argument indexing, a
kind of skip indexing, they describe
it on their GitHub homepage, can do it:

/* Scryer Prolog 0.9.4-415 */
?- app(X,Y,[1]).
X = [], Y = [1]
; X = [1], Y = [].

And the ghost from my cabinet, formerly
Jekejeke Prolog, which does a little bit more
than skip indexing, but still not the same deep
indexing as in SWI-Prolog can also do it:

/* Jekejeke Runtime 1.7.3 */
?- app(X,Y,[1]).
X = [], Y = [1];
X = [1], Y = [].

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Shocking revelation, I found two significant
bugs in my age old indexer code base yesterday.
How can an eGovernment ever trust any Prolog
system? These were bugs that typically go

unnoticed by lets say a Rust type system.
Would possibly require deep axiomatization
or heavy fuzzy testing of the code, or a
combination of both.

LoL

Bye

Mild Shock schrieb:

I made the observation while looking at
debugger traces, choice point elimination,
driven by indexes, also determines what
FAIL/REDO ports a debugger shows.

What is amazing Scryer Prolog, which has
a tamer version of multi-argument indexing, a
kind of skip indexing, they describe
it on their GitHub homepage, can do it:

/* Scryer Prolog 0.9.4-415 */
?- app(X,Y,[1]).
   X = [], Y = [1]
;  X = [1], Y = [].

And the ghost from my cabinet, formerly
Jekejeke Prolog, which does a little bit more
than skip indexing, but still not the same deep
indexing as in SWI-Prolog can also do it:

/* Jekejeke Runtime 1.7.3 */
?- app(X,Y,[1]).
X = [], Y = [1];
X = [1], Y = [].

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Is there an easier certification with a Prolog
system that is written 100% in Prolog itself. Maybe
or maybe not, I don't know, it feels a little bit

like having implemented a Prolog system by taking
the declarative specification of in the appendix
of the ISO core standard, except I didn't use the

always declarative style of the ISO appendix. It
doesn't make any sense practically for a declarative
style and have later some Prolog system which is either

inefficient because the choice points explode or
something impractical without I/O effects like the
html//1 thingy in SWI-Prolog.

Bye

Mild Shock schrieb:

Hi,

Shocking revelation, I found two significant
bugs in my age old indexer code base yesterday.
How can an eGovernment ever trust any Prolog
system? These were bugs that typically go

unnoticed by lets say a Rust type system.
Would possibly require deep axiomatization
or heavy fuzzy testing of the code, or a
combination of both.

LoL

Bye

Mild Shock schrieb:

I made the observation while looking at
debugger traces, choice point elimination,
driven by indexes, also determines what
FAIL/REDO ports a debugger shows.

What is amazing Scryer Prolog, which has
a tamer version of multi-argument indexing, a
kind of skip indexing, they describe
it on their GitHub homepage, can do it:

/* Scryer Prolog 0.9.4-415 */
?- app(X,Y,[1]).
    X = [], Y = [1]
;  X = [1], Y = [].

And the ghost from my cabinet, formerly
Jekejeke Prolog, which does a little bit more
than skip indexing, but still not the same deep
indexing as in SWI-Prolog can also do it:

/* Jekejeke Runtime 1.7.3 */
?- app(X,Y,[1]).
X = [], Y = [1];
X = [1], Y = [].

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Most of the libraries and the system are design so
that native is a last resort. So most functionality is
Prolog and in a few instances there is a native call:

- Main Design:

Prolog (a lot of it) --> Native (very little)

This design, concerning the call control flow, is only
broken in the top level, and in very few places, like the
browser and a web server. The top-level is a native entry

point and it needs to reach into Prolog, and the
libraries library(react) and library(spin) provide call
back facilities for the browser and a web

server event handlers:

- 2nd Design:

Native (top-level, react and spin) --> Prolog

There is no idea at all that the Prolog system supports
any iterators. I did this in the past. But the Prolog
system gets simpler without the viewpoint that the

interface should support iterators. SWI-Prolog always
invests heavily to support iterators. Based on the
rather negative experience with formerly Jekejeke Prolog

we tried to completely avoid any iterator interface.

Bye

Mild Shock schrieb:

Hi,

Is there an easier certification with a Prolog
system that is written 100% in Prolog itself. Maybe
or maybe not, I don't know, it feels a little bit

like having implemented a Prolog system by taking
the declarative specification of in the appendix
of the ISO core standard, except I didn't use the

always declarative style of the ISO appendix. It
doesn't make any sense practically for a declarative
style and have later some Prolog system which is either

inefficient because the choice points explode or
something impractical without I/O effects like the
html//1 thingy in SWI-Prolog.

Bye

Mild Shock schrieb:

Hi,

Shocking revelation, I found two significant
bugs in my age old indexer code base yesterday.
How can an eGovernment ever trust any Prolog
system? These were bugs that typically go

unnoticed by lets say a Rust type system.
Would possibly require deep axiomatization
or heavy fuzzy testing of the code, or a
combination of both.

LoL

Bye

Mild Shock schrieb:

I made the observation while looking at
debugger traces, choice point elimination,
driven by indexes, also determines what
FAIL/REDO ports a debugger shows.

What is amazing Scryer Prolog, which has
a tamer version of multi-argument indexing, a
kind of skip indexing, they describe
it on their GitHub homepage, can do it:

/* Scryer Prolog 0.9.4-415 */
?- app(X,Y,[1]).
    X = [], Y = [1]
;  X = [1], Y = [].

And the ghost from my cabinet, formerly
Jekejeke Prolog, which does a little bit more
than skip indexing, but still not the same deep
indexing as in SWI-Prolog can also do it:

/* Jekejeke Runtime 1.7.3 */
?- app(X,Y,[1]).
X = [], Y = [1];
X = [1], Y = [].

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

There is one thing that currently causes me headaches.
So far the Dogelog Player design didn't have a big
ping pong from Prolog to Native and back.

It has the Main Design with Prolog --> Native, and
the 2nd Design with Native --> Prolog. We also managed
to do some clause indexing preparation

in the Main Design, so we have this separation of concerning
currently for first argument indexing:

- Computation of Clause Key Value: Prolog
The computation of the Key Value of a clause is done
at compile time in pure Prolog. There are two strategies,
for dynamic predicates the key is directly taken from
the first argument of the head.

For static predicates the body of the claue is also
analyzed, and this can also give a key, like for
exaple if the body as a unification X = C, and X
appears as first argument, the the key can be taken from C.

- Computation of Goal/Head Key Value: Native
The clauses are supplied with their Key Value, and
Native code does add them with indexing. Or update the
index when a clause is removed.

The computation of the Key Value of a goal or clause
head is done a runtime in Native. And then the lookup
is done natively as well.

Now I wonder how I can bring multi-argument JIT Indexing
from formerly Jekejeke Prolog into the picture, and still
have a high degree of 100% Prolog code. Some hurdles:

- Clause Key Value on Demand: Native -> Prolog
So if I would keep the scheme that Prolog determines the
clause Key Values. And if I would do this on demand,
I would have a Native -> Prolog call.

- Clauses would need decompile:
Even if I implement such a Native -> Prolog hook,
the problem is Clauses have not the compile time format
at runtime. So the my old 100% Prolog code for Clause
Key Value will not work, requires first decompilation.

- YAP approach:
I have an old paper from YAP. For the indexing they
are scanning the native clause code. I didn't double
check yet what SWI-Prolog (has JIT-ing) or Scryer Prolog
(doesn't do it JIT style?). Etc...

- What else?

Well its not a big headache, but a kind of blocker,
before I decide what to do. There are a couple of options
to get out of the dilemma, and turn the Prolog systems

around, and make it 100% Prolog again. Its like the
big beautiful bill by Donald Trump. Make Prolog
100% Prolog again!

LoL

Bye

Mild Shock schrieb:

Hi,

Most of the libraries and the system are design so
that native is a last resort. So most functionality is
Prolog and in a few instances there is a native call:

- Main Design:

  Prolog (a lot of it) --> Native (very little)

This design, concerning the call control flow, is only
broken in the top level, and in very few places, like the
browser and a web server. The top-level is a native entry

point and it needs to reach into Prolog, and the
libraries library(react) and library(spin) provide call
back facilities for the browser and a web

server event handlers:

- 2nd Design:

  Native (top-level, react and spin) --> Prolog

There is no idea at all that the Prolog system supports
any iterators. I did this in the past. But the Prolog
system gets simpler without the viewpoint that the

interface should support iterators. SWI-Prolog always
invests heavily to support iterators. Based on the
rather negative experience with formerly Jekejeke Prolog

we tried to completely avoid any iterator interface.

Bye

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

I have really interesting ghosts in by cabinet.
Not only old software, also crazy people like
Bart Demoen. And the good thing everything is

still available through Google Groups that
has nicely preserved comp.lang.prolog. According
Barty Boy the term "Choice Point Elimination"

didn't really exist:

Anyway, I have no idea what "choice point
elimination" is supposed to refer to in literature.

Literally, "choice point elimination" should mean
something related to: a choicepoint was created
some technique eliminates that choice point

https://groups.google.com/g/comp.lang.prolog/c/qnwD_TEG4xg/m/LMiDtFY1dQIJ

Well he is somehow right if "elimination" is
interpreted as creating and then destroying.
But it could also mean preventing the creation

of a choice point. You never know from the
far of a the flemish / dutch mountains what a
term means. Even if somebody presents a corpus

resarch as I did.

Bye

Mild Shock schrieb:

Hi,

There is one thing that currently causes me headaches.
So far the Dogelog Player design didn't have a big
ping pong from Prolog to Native and back.

It has the Main Design with Prolog --> Native, and
the 2nd Design with Native --> Prolog. We also managed
to do some clause indexing preparation

in the Main Design, so we have this separation of concerning
currently for first argument indexing:

- Computation of Clause Key Value: Prolog
  The computation of the Key Value of a clause is done
  at compile time in pure Prolog. There are two strategies,
  for dynamic predicates the key is directly taken from
  the first argument of the head.

  For static predicates the body of the claue is also
  analyzed, and this can also give a key, like for
  exaple if the body as a unification X = C, and X
  appears as first argument, the the key can be taken from C.

- Computation of Goal/Head Key Value: Native
  The clauses are supplied with their Key Value, and
  Native code does add them with indexing. Or update the
  index when a clause is removed.

  The computation of the Key Value of a goal or clause
  head is done a runtime in Native. And then the lookup
  is done natively as well.

Now I wonder how I can bring multi-argument JIT Indexing
from formerly Jekejeke Prolog into the picture, and still
have a high degree of 100% Prolog code. Some hurdles:

- Clause Key Value on Demand: Native -> Prolog
  So if I would keep the scheme that Prolog determines the
  clause Key Values. And if I would do this on demand,
  I would have a Native -> Prolog call.

- Clauses would need decompile:
  Even if I implement such a Native -> Prolog hook,
  the problem is Clauses have not the compile time format
  at runtime. So the my old 100% Prolog code for Clause
  Key Value will not work, requires first decompilation.

- YAP approach:
  I have an old paper from YAP. For the indexing they
  are scanning the native clause code. I didn't double
  check yet what SWI-Prolog (has JIT-ing) or Scryer Prolog
  (doesn't do it JIT style?). Etc...

- What else?

Well its not a big headache, but a kind of blocker,
before I decide what to do. There are a couple of options
to get out of the dilemma, and turn the Prolog systems

around, and make it 100% Prolog again. Its like the
big beautiful bill by Donald Trump. Make Prolog
100% Prolog again!

LoL

Bye

Mild Shock schrieb:

Hi,

Most of the libraries and the system are design so
that native is a last resort. So most functionality is
Prolog and in a few instances there is a native call:

- Main Design:

   Prolog (a lot of it) --> Native (very little)

This design, concerning the call control flow, is only
broken in the top level, and in very few places, like the
browser and a web server. The top-level is a native entry

point and it needs to reach into Prolog, and the
libraries library(react) and library(spin) provide call
back facilities for the browser and a web

server event handlers:

- 2nd Design:

   Native (top-level, react and spin) --> Prolog

There is no idea at all that the Prolog system supports
any iterators. I did this in the past. But the Prolog
system gets simpler without the viewpoint that the

interface should support iterators. SWI-Prolog always
invests heavily to support iterators. Based on the
rather negative experience with formerly Jekejeke Prolog

we tried to completely avoid any iterator interface.

Bye

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

But after all these years, Wikipedia still mentions:

Choice Point Elimination https://en.wikipedia.org/wiki/Comparison_of_Prolog_implementations#Optimizations

Still the complete moron Bart Demoen, drowning in
Dunning-Kruger syndrom, of incompetent people working
in the wrong domain, accused me of:

gives me the feeling that "choice point elimination" is
something jb coined, and does not belong to traditional
Prolog implementation terminology.

So what does Choice Point Elimination mean?

From compiler optimization I would guess elimination
and avoidance have the similar meaning, whereas I would
prefer elimination. Elimination could mean to eliminate

an intermediate step. Like in quantifier elimination,
you eliminate something that was already there but you
could somehow get rid of it through some transformation,

you don't really avoid it. So the Physics PhDs Bart Demoen
which had no education in mathematical logic is no
way excused. He was just exposing the dark side of

wrong people in wrong places.

Bye

Mild Shock schrieb:

Hi,

I have really interesting ghosts in by cabinet.
Not only old software, also crazy people like
Bart Demoen. And the good thing everything is

still available through Google Groups that
has nicely preserved comp.lang.prolog. According
Barty Boy the term "Choice Point Elimination"

didn't really exist:

Anyway, I have no idea what "choice point
elimination" is supposed to refer to in literature.

Literally, "choice point elimination" should mean
something related to: a choicepoint was created
some technique eliminates that choice point

https://groups.google.com/g/comp.lang.prolog/c/qnwD_TEG4xg/m/LMiDtFY1dQIJ

Well he is somehow right if "elimination" is
interpreted as creating and then destroying.
But it could also mean preventing the creation

of a choice point. You never know from the
far of a the flemish / dutch mountains what a
term means. Even if somebody presents a corpus

resarch as I did.

Bye

Mild Shock schrieb:

Hi,

There is one thing that currently causes me headaches.
So far the Dogelog Player design didn't have a big
ping pong from Prolog to Native and back.

It has the Main Design with Prolog --> Native, and
the 2nd Design with Native --> Prolog. We also managed
to do some clause indexing preparation

in the Main Design, so we have this separation of concerning
currently for first argument indexing:

- Computation of Clause Key Value: Prolog
   The computation of the Key Value of a clause is done
   at compile time in pure Prolog. There are two strategies,
   for dynamic predicates the key is directly taken from
   the first argument of the head.

   For static predicates the body of the claue is also
   analyzed, and this can also give a key, like for
   exaple if the body as a unification X = C, and X
   appears as first argument, the the key can be taken from C.

- Computation of Goal/Head Key Value: Native
   The clauses are supplied with their Key Value, and
   Native code does add them with indexing. Or update the
   index when a clause is removed.

   The computation of the Key Value of a goal or clause
   head is done a runtime in Native. And then the lookup
   is done natively as well.

Now I wonder how I can bring multi-argument JIT Indexing
from formerly Jekejeke Prolog into the picture, and still
have a high degree of 100% Prolog code. Some hurdles:

- Clause Key Value on Demand: Native -> Prolog
   So if I would keep the scheme that Prolog determines the
   clause Key Values. And if I would do this on demand,
   I would have a Native -> Prolog call.

- Clauses would need decompile:
   Even if I implement such a Native -> Prolog hook,
   the problem is Clauses have not the compile time format
   at runtime. So the my old 100% Prolog code for Clause
   Key Value will not work, requires first decompilation.

- YAP approach:
   I have an old paper from YAP. For the indexing they
   are scanning the native clause code. I didn't double
   check yet what SWI-Prolog (has JIT-ing) or Scryer Prolog
   (doesn't do it JIT style?). Etc...

- What else?

Well its not a big headache, but a kind of blocker,
before I decide what to do. There are a couple of options
to get out of the dilemma, and turn the Prolog systems

around, and make it 100% Prolog again. Its like the
big beautiful bill by Donald Trump. Make Prolog
100% Prolog again!

LoL

Bye

Mild Shock schrieb:

Hi,

Most of the libraries and the system are design so
that native is a last resort. So most functionality is
Prolog and in a few instances there is a native call:

- Main Design:

   Prolog (a lot of it) --> Native (very little)

This design, concerning the call control flow, is only
broken in the top level, and in very few places, like the
browser and a web server. The top-level is a native entry

point and it needs to reach into Prolog, and the
libraries library(react) and library(spin) provide call
back facilities for the browser and a web

server event handlers:

- 2nd Design:

   Native (top-level, react and spin) --> Prolog

There is no idea at all that the Prolog system supports
any iterators. I did this in the past. But the Prolog
system gets simpler without the viewpoint that the

interface should support iterators. SWI-Prolog always
invests heavily to support iterators. Based on the
rather negative experience with formerly Jekejeke Prolog

we tried to completely avoid any iterator interface.

Bye

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

How long willl I piss on Bart Demoen?
I don't know, as long as it takes to
clean up my cabinet full of ghosts.

After that I might do some LogNonsenseTalk
bashing again, didn't do a for a long time.
But since Paulo Moura was deciple of

following Bart Demoen in mobbing, he
deserves nothing better. But LogNonsenseTalk
is not yet a ghost, not retired yet,

still a walking Zombie...

LoL

Bye

Mild Shock schrieb:

Hi,

But after all these years, Wikipedia still mentions:

Choice Point Elimination https://en.wikipedia.org/wiki/Comparison_of_Prolog_implementations#Optimizations

Still the complete moron Bart Demoen, drowning in
Dunning-Kruger syndrom, of incompetent people working
in the wrong domain, accused me of:

gives me the feeling that "choice point elimination" is
something jb coined, and does not belong to traditional
Prolog implementation terminology.

So what does Choice Point Elimination mean?

From compiler optimization I would guess elimination
and avoidance have the similar meaning, whereas I would
prefer elimination. Elimination could mean to eliminate

an intermediate step. Like in quantifier elimination,
you eliminate something that was already there but you
could somehow get rid of it through some transformation,

you don't really avoid it. So the Physics PhDs Bart Demoen
which had no education in mathematical logic is no
way excused. He was just exposing the dark side of

wrong people in wrong places.

Bye

Mild Shock schrieb:

Hi,

I have really interesting ghosts in by cabinet.
Not only old software, also crazy people like
Bart Demoen. And the good thing everything is

still available through Google Groups that
has nicely preserved comp.lang.prolog. According
Barty Boy the term "Choice Point Elimination"

didn't really exist:

Anyway, I have no idea what "choice point
elimination" is supposed to refer to in literature.
;
Literally, "choice point elimination" should mean
something related to: a choicepoint was created
some technique eliminates that choice point

https://groups.google.com/g/comp.lang.prolog/c/qnwD_TEG4xg/m/LMiDtFY1dQIJ

Well he is somehow right if "elimination" is
interpreted as creating and then destroying.
But it could also mean preventing the creation

of a choice point. You never know from the
far of a the flemish / dutch mountains what a
term means. Even if somebody presents a corpus

resarch as I did.

Bye

Mild Shock schrieb:

Hi,

There is one thing that currently causes me headaches.
So far the Dogelog Player design didn't have a big
ping pong from Prolog to Native and back.

It has the Main Design with Prolog --> Native, and
the 2nd Design with Native --> Prolog. We also managed
to do some clause indexing preparation

in the Main Design, so we have this separation of concerning
currently for first argument indexing:

- Computation of Clause Key Value: Prolog
   The computation of the Key Value of a clause is done
   at compile time in pure Prolog. There are two strategies,
   for dynamic predicates the key is directly taken from
   the first argument of the head.

   For static predicates the body of the claue is also
   analyzed, and this can also give a key, like for
   exaple if the body as a unification X = C, and X
   appears as first argument, the the key can be taken from C.

- Computation of Goal/Head Key Value: Native
   The clauses are supplied with their Key Value, and
   Native code does add them with indexing. Or update the
   index when a clause is removed.

   The computation of the Key Value of a goal or clause
   head is done a runtime in Native. And then the lookup
   is done natively as well.

Now I wonder how I can bring multi-argument JIT Indexing
from formerly Jekejeke Prolog into the picture, and still
have a high degree of 100% Prolog code. Some hurdles:

- Clause Key Value on Demand: Native -> Prolog
   So if I would keep the scheme that Prolog determines the
   clause Key Values. And if I would do this on demand,
   I would have a Native -> Prolog call.

- Clauses would need decompile:
   Even if I implement such a Native -> Prolog hook,
   the problem is Clauses have not the compile time format
   at runtime. So the my old 100% Prolog code for Clause
   Key Value will not work, requires first decompilation.

- YAP approach:
   I have an old paper from YAP. For the indexing they
   are scanning the native clause code. I didn't double
   check yet what SWI-Prolog (has JIT-ing) or Scryer Prolog
   (doesn't do it JIT style?). Etc...

- What else?

Well its not a big headache, but a kind of blocker,
before I decide what to do. There are a couple of options
to get out of the dilemma, and turn the Prolog systems

around, and make it 100% Prolog again. Its like the
big beautiful bill by Donald Trump. Make Prolog
100% Prolog again!

LoL

Bye

Mild Shock schrieb:

Hi,

Most of the libraries and the system are design so
that native is a last resort. So most functionality is
Prolog and in a few instances there is a native call:

- Main Design:

   Prolog (a lot of it) --> Native (very little)

This design, concerning the call control flow, is only
broken in the top level, and in very few places, like the
browser and a web server. The top-level is a native entry

point and it needs to reach into Prolog, and the
libraries library(react) and library(spin) provide call
back facilities for the browser and a web

server event handlers:

- 2nd Design:

   Native (top-level, react and spin) --> Prolog

There is no idea at all that the Prolog system supports
any iterators. I did this in the past. But the Prolog
system gets simpler without the viewpoint that the

interface should support iterators. SWI-Prolog always
invests heavily to support iterators. Based on the
rather negative experience with formerly Jekejeke Prolog

we tried to completely avoid any iterator interface.

Bye

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

But I shouldn't waste too much time.
One shouldn't punish people for just
being plain stupid.

Like for example this clueless french
philosopher who had a lot of troubles
with non-classical logic.

His brain tried to eliminate non-classical
logic, it was keen on avoiding non-classical
logic. A typical species of a human with

an extremly small brain, again working
in the wrong place!

Bye

P.S.: Maybe this a Poincaré thingy? Poincaré
was a strong critic of logicism (as championed
by Frege and Russell) and of Hilbert’s
formalist program.

But, he did not formally use or promote systems
like intuitionistic logic, modal logic, or
relevance logic. His logical framework remained
within the bounds of classical logic,

though he was skeptical of excessive formalism.
He thought formal systems could miss the creative
and synthetic nature of mathematical
invention.

Mild Shock schrieb:

Hi,

How long willl I piss on Bart Demoen?
I don't know, as long as it takes to
clean up my cabinet full of ghosts.

After that I might do some LogNonsenseTalk
bashing again, didn't do a for a long time.
But since Paulo Moura was deciple of

following Bart Demoen in mobbing, he
deserves nothing better. But LogNonsenseTalk
is not yet a ghost, not retired yet,

still a walking Zombie...

LoL

Bye

Mild Shock schrieb:

Hi,

But after all these years, Wikipedia still mentions:

Choice Point Elimination
https://en.wikipedia.org/wiki/Comparison_of_Prolog_implementations#Optimizations

Still the complete moron Bart Demoen, drowning in
Dunning-Kruger syndrom, of incompetent people working
in the wrong domain, accused me of:

gives me the feeling that "choice point elimination" is
something jb coined, and does not belong to traditional
Prolog implementation terminology.

So what does Choice Point Elimination mean?

 From compiler optimization I would guess elimination
and avoidance have the similar meaning, whereas I would
prefer elimination. Elimination could mean to eliminate

an intermediate step. Like in quantifier elimination,
you eliminate something that was already there but you
could somehow get rid of it through some transformation,

you don't really avoid it. So the Physics PhDs Bart Demoen
which had no education in mathematical logic is no
way excused. He was just exposing the dark side of

wrong people in wrong places.

Bye

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog


Interestingly, DCG is also affect. Here a
DCG take of an append app/3, it has the 2nd
and 3rd argument swapped:

?- [user].
app([]) --> [].
app([X|Y]) --> [X], app(Y).
^D

Looks like an append, taking the argument swap
into account, the A=B is redundant, could
be optimized away:

/* SWI-Prolog 9.3.25 */
?- listing(app/3).
app([], A, B) :-
A=B.
app([A|B], [A|C], D) :-
app(B, C, D).

And works like an append, again taking the
argument swap into account:

?- app([1],X,[2,3]).
X = [1, 2, 3].

Now the multi-argument indexing test, still
taking the argument swap into account;

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 3]: app(X, [1], Y).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

Versus:

/* SWI-Prolog 9.3.25 */
?- app(X, [1], Y).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

That false/0 and not fail/0 is now all over the place,
I don't mean in person but for example here:

?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
false.

Is a little didactical nightmare.

Syntactic unification has mathematical axioms (1978),
to fully formalize unifcation you would need to
formalize both (=)/2 and (≠)/2 (sic!), otherwise you
rely on some negation as failure concept.

Keith L. Clark, Negation as Failure https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11

You can realize a subset of a mixture of (=)/2
and (≠)/2 in the form of a vanilla unify Prolog
predicate using some of the meta programming
facilities of Prolog, like var/1 and having some

negation as failure reading:

/* Vanilla Unify */
unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
unify(V, T) :- var(V), !, V = T.
unify(S, W) :- var(W), !, W = S.
unify(S, T) :- functor(S, F, N), functor(T, F, N),
S =.. [F|L], T =.. [F|R], maplist(unify, L, R).

I indeed get:

?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
false.

If the vanilla unify/2 already fails then unify
with and without subject to occurs check, will also
fail, and unify with and without ability to
handle rational terms, will also fail:

Bye

Mild Shock schrieb:

Interestingly, DCG is also affect. Here a
DCG take of an append app/3, it has the 2nd
and 3rd argument swapped:

?- [user].
app([]) --> [].
app([X|Y]) --> [X], app(Y).
^D

Looks like an append, taking the argument swap
into account, the A=B is redundant, could
be optimized away:

/* SWI-Prolog 9.3.25 */
?- listing(app/3).
app([], A, B) :-
    A=B.
app([A|B], [A|C], D) :-
    app(B, C, D).

And works like an append, again taking the
argument swap into account:

?- app([1],X,[2,3]).
X = [1, 2, 3].

Now the multi-argument indexing test, still
taking the argument swap into account;

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 3]: app(X, [1], Y).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

Versus:

/* SWI-Prolog 9.3.25 */
?- app(X, [1], Y).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Now somebody was so friendly to spear head
a new Don Quixote attempt in fighting the
windmills of compare/3. Interestingly my

favorite counter example still goes through:

?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
compare_with_stack(C, X, Y).
X = X-0-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (<).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
compare_with_stack(C, Z, Y).
H = H-9-7-6-5-4-3-2-1-0,
Z = H-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (>).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X =
X-0-9-7-6-5-4-3-2-1,
compare_with_stack(C, Z, X).
H = H-9-7-6-5-4-3-2-1-0,
Z = X, X = X-0-9-7-6-5-4-3-2-1,
C = (=).

I posted it here in March 2023:

Careful with compare/3 and Brent algorithm https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413

Its based that rational terms are indeed in
some relation to rational numbers. The above
terms are related to:

10/81 = 0.(123456790) = 0.12345679(02345679)

Bye

Mild Shock schrieb:

Hi,

That false/0 and not fail/0 is now all over the place,
I don't mean in person but for example here:

?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
false.

Is a little didactical nightmare.

Syntactic unification has mathematical axioms (1978),
to fully formalize unifcation you would need to
formalize both (=)/2 and (≠)/2 (sic!), otherwise you
rely on some negation as failure concept.

Keith L. Clark, Negation as Failure https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11

You can realize a subset of a mixture of (=)/2
and (≠)/2 in the form of a vanilla unify Prolog
predicate using some of the meta programming
facilities of Prolog, like var/1 and having some

negation as failure reading:

/* Vanilla Unify */
unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
unify(V, T) :- var(V), !, V = T.
unify(S, W) :- var(W), !, W = S.
unify(S, T) :- functor(S, F, N), functor(T, F, N),
     S =.. [F|L], T =.. [F|R], maplist(unify, L, R).

I indeed get:

?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
false.

If the vanilla unify/2 already fails then unify
with and without subject to occurs check, will also
fail, and unify with and without ability to
handle rational terms, will also fail:

Bye

Mild Shock schrieb:

Interestingly, DCG is also affect. Here a
DCG take of an append app/3, it has the 2nd
and 3rd argument swapped:

?- [user].
app([]) --> [].
app([X|Y]) --> [X], app(Y).
^D

Looks like an append, taking the argument swap
into account, the A=B is redundant, could
be optimized away:

/* SWI-Prolog 9.3.25 */
?- listing(app/3).
app([], A, B) :-
     A=B.
app([A|B], [A|C], D) :-
     app(B, C, D).

And works like an append, again taking the
argument swap into account:

?- app([1],X,[2,3]).
X = [1, 2, 3].

Now the multi-argument indexing test, still
taking the argument swap into account;

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 3]: app(X, [1], Y).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

Versus:

/* SWI-Prolog 9.3.25 */
?- app(X, [1], Y).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Corr.: Small typo in the number
expansion itself, should read:

10/81 = 0.(123456790) = 0.12345679(012345679)

Mild Shock schrieb:

Hi,

Now somebody was so friendly to spear head
a new Don Quixote attempt in fighting the
windmills of compare/3. Interestingly my

favorite counter example still goes through:

?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
   compare_with_stack(C, X, Y).
X = X-0-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (<).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
   compare_with_stack(C, Z, Y).
H = H-9-7-6-5-4-3-2-1-0,
Z = H-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (>).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X = X-0-9-7-6-5-4-3-2-1,
   compare_with_stack(C, Z, X).
H = H-9-7-6-5-4-3-2-1-0,
Z = X, X = X-0-9-7-6-5-4-3-2-1,
C = (=).

I posted it here in March 2023:

Careful with compare/3 and Brent algorithm https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413

Its based that rational terms are indeed in
some relation to rational numbers. The above
terms are related to:

10/81 = 0.(123456790) = 0.12345679(02345679)

Bye

Mild Shock schrieb:

Hi,

That false/0 and not fail/0 is now all over the place,
I don't mean in person but for example here:

?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
false.

Is a little didactical nightmare.

Syntactic unification has mathematical axioms (1978),
to fully formalize unifcation you would need to
formalize both (=)/2 and (≠)/2 (sic!), otherwise you
rely on some negation as failure concept.

Keith L. Clark, Negation as Failure
https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11

You can realize a subset of a mixture of (=)/2
and (≠)/2 in the form of a vanilla unify Prolog
predicate using some of the meta programming
facilities of Prolog, like var/1 and having some

negation as failure reading:

/* Vanilla Unify */
unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
unify(V, T) :- var(V), !, V = T.
unify(S, W) :- var(W), !, W = S.
unify(S, T) :- functor(S, F, N), functor(T, F, N),
      S =.. [F|L], T =.. [F|R], maplist(unify, L, R).

I indeed get:

?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
false.

If the vanilla unify/2 already fails then unify
with and without subject to occurs check, will also
fail, and unify with and without ability to
handle rational terms, will also fail:

Bye

Mild Shock schrieb:

Interestingly, DCG is also affect. Here a
DCG take of an append app/3, it has the 2nd
and 3rd argument swapped:

?- [user].
app([]) --> [].
app([X|Y]) --> [X], app(Y).
^D

Looks like an append, taking the argument swap
into account, the A=B is redundant, could
be optimized away:

/* SWI-Prolog 9.3.25 */
?- listing(app/3).
app([], A, B) :-
     A=B.
app([A|B], [A|C], D) :-
     app(B, C, D).

And works like an append, again taking the
argument swap into account:

?- app([1],X,[2,3]).
X = [1, 2, 3].

Now the multi-argument indexing test, still
taking the argument swap into account;

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 3]: app(X, [1], Y).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

Versus:

/* SWI-Prolog 9.3.25 */
?- app(X, [1], Y).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Maybe AGI should take over proving.
Just take the humans out of the loop
of any programming, it leads to nowhere.

Bye

Julio Di Egidio schrieb:

But we must thank MS for the nail in that coffin, too: they can't
be satisfied with just a Lean broken by design, they must own the
whole compartment: only poisoned meatballs for the public...

-Julio

Mild Shock schrieb:

Corr.: Small typo in the number
expansion itself, should read:

10/81 = 0.(123456790) = 0.12345679(012345679)

Mild Shock schrieb:

Hi,

Now somebody was so friendly to spear head
a new Don Quixote attempt in fighting the
windmills of compare/3. Interestingly my

favorite counter example still goes through:

?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, X, Y).
X = X-0-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (<).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, Z, Y).
H = H-9-7-6-5-4-3-2-1-0,
Z = H-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (>).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X =
X-0-9-7-6-5-4-3-2-1,
    compare_with_stack(C, Z, X).
H = H-9-7-6-5-4-3-2-1-0,
Z = X, X = X-0-9-7-6-5-4-3-2-1,
C = (=).

I posted it here in March 2023:

Careful with compare/3 and Brent algorithm
https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413


Its based that rational terms are indeed in
some relation to rational numbers. The above
terms are related to:

10/81 = 0.(123456790) = 0.12345679(02345679)

Bye

Mild Shock schrieb:

Hi,

That false/0 and not fail/0 is now all over the place,
I don't mean in person but for example here:

?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
false.

Is a little didactical nightmare.

Syntactic unification has mathematical axioms (1978),
to fully formalize unifcation you would need to
formalize both (=)/2 and (≠)/2 (sic!), otherwise you
rely on some negation as failure concept.

Keith L. Clark, Negation as Failure
https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11

You can realize a subset of a mixture of (=)/2
and (≠)/2 in the form of a vanilla unify Prolog
predicate using some of the meta programming
facilities of Prolog, like var/1 and having some

negation as failure reading:

/* Vanilla Unify */
unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
unify(V, T) :- var(V), !, V = T.
unify(S, W) :- var(W), !, W = S.
unify(S, T) :- functor(S, F, N), functor(T, F, N),
      S =.. [F|L], T =.. [F|R], maplist(unify, L, R).

I indeed get:

?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
false.

If the vanilla unify/2 already fails then unify
with and without subject to occurs check, will also
fail, and unify with and without ability to
handle rational terms, will also fail:

Bye

Mild Shock schrieb:

Interestingly, DCG is also affect. Here a
DCG take of an append app/3, it has the 2nd
and 3rd argument swapped:

?- [user].
app([]) --> [].
app([X|Y]) --> [X], app(Y).
^D

Looks like an append, taking the argument swap
into account, the A=B is redundant, could
be optimized away:

/* SWI-Prolog 9.3.25 */
?- listing(app/3).
app([], A, B) :-
     A=B.
app([A|B], [A|C], D) :-
     app(B, C, D).

And works like an append, again taking the
argument swap into account:

?- app([1],X,[2,3]).
X = [1, 2, 3].

Now the multi-argument indexing test, still
taking the argument swap into account;

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 3]: app(X, [1], Y).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

Versus:

/* SWI-Prolog 9.3.25 */
?- app(X, [1], Y).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Having 2544 issues is probably a bad sign.
I find this many issues here:

https://github.com/rocq-prover/rocq/issues

Mostlikely 90% of the issues can be move to
the new discussion feature of GitHub.

LoL

Bye

P.S.: Same holds for Scryer Prolog with 406 issues.

Mild Shock schrieb:

Hi,

Maybe AGI should take over proving.
Just take the humans out of the loop
of any programming, it leads to nowhere.

Bye

Julio Di Egidio schrieb:

But we must thank MS for the nail in that coffin, too: they can't
be satisfied with just a Lean broken by design, they must own the
whole compartment: only poisoned meatballs for the public...

-Julio

Mild Shock schrieb:

Corr.: Small typo in the number
expansion itself, should read:

10/81 = 0.(123456790) = 0.12345679(012345679)

Mild Shock schrieb:

Hi,

Now somebody was so friendly to spear head
a new Don Quixote attempt in fighting the
windmills of compare/3. Interestingly my

favorite counter example still goes through:

?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, X, Y).
X = X-0-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (<).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, Z, Y).
H = H-9-7-6-5-4-3-2-1-0,
Z = H-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (>).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X =
X-0-9-7-6-5-4-3-2-1,
    compare_with_stack(C, Z, X).
H = H-9-7-6-5-4-3-2-1-0,
Z = X, X = X-0-9-7-6-5-4-3-2-1,
C = (=).

I posted it here in March 2023:

Careful with compare/3 and Brent algorithm
https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413


Its based that rational terms are indeed in
some relation to rational numbers. The above
terms are related to:

10/81 = 0.(123456790) = 0.12345679(02345679)

Bye

Mild Shock schrieb:

Hi,

That false/0 and not fail/0 is now all over the place,
I don't mean in person but for example here:

?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
false.

Is a little didactical nightmare.

Syntactic unification has mathematical axioms (1978),
to fully formalize unifcation you would need to
formalize both (=)/2 and (≠)/2 (sic!), otherwise you
rely on some negation as failure concept.

Keith L. Clark, Negation as Failure
https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11

You can realize a subset of a mixture of (=)/2
and (≠)/2 in the form of a vanilla unify Prolog
predicate using some of the meta programming
facilities of Prolog, like var/1 and having some

negation as failure reading:

/* Vanilla Unify */
unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
unify(V, T) :- var(V), !, V = T.
unify(S, W) :- var(W), !, W = S.
unify(S, T) :- functor(S, F, N), functor(T, F, N),
      S =.. [F|L], T =.. [F|R], maplist(unify, L, R).

I indeed get:

?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
false.

If the vanilla unify/2 already fails then unify
with and without subject to occurs check, will also
fail, and unify with and without ability to
handle rational terms, will also fail:

Bye

Mild Shock schrieb:

Interestingly, DCG is also affect. Here a
DCG take of an append app/3, it has the 2nd
and 3rd argument swapped:

?- [user].
app([]) --> [].
app([X|Y]) --> [X], app(Y).
^D

Looks like an append, taking the argument swap
into account, the A=B is redundant, could
be optimized away:

/* SWI-Prolog 9.3.25 */
?- listing(app/3).
app([], A, B) :-
     A=B.
app([A|B], [A|C], D) :-
     app(B, C, D).

And works like an append, again taking the
argument swap into account:

?- app([1],X,[2,3]).
X = [1, 2, 3].

Now the multi-argument indexing test, still
taking the argument swap into account;

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 3]: app(X, [1], Y).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

Versus:

/* SWI-Prolog 9.3.25 */
?- app(X, [1], Y).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

1. Everybody’s a programmer now
The barrier to entry dropped dramatically — you can
become a "developer" with a few online tutorials
and a GitHub account.

2. Everybody’s an academic now
Academia expanded, but standards often fell. In
some places, it's publish or perish, so paper
mills and fake research flourish.

3. Signal Collapse ↔ Systemic Uncertainty
Credentials lose meaning, No reliable markers of
skill, Fragile systems built on shallow knowledge

4. Signal Collapse ↔ Systemic Uncertainty
Quantity overwhelms quality, Important truths get
buried, Bad signals drown good ones

Etc..

Bye

Mild Shock schrieb:

Hi,

Having 2544 issues is probably a bad sign.
I find this many issues here:

https://github.com/rocq-prover/rocq/issues

Mostlikely 90% of the issues can be move to
the new discussion feature of GitHub.

LoL

Bye

P.S.: Same holds for Scryer Prolog with 406 issues.

Mild Shock schrieb:

Hi,

Maybe AGI should take over proving.
Just take the humans out of the loop
of any programming, it leads to nowhere.

Bye

Julio Di Egidio schrieb:

But we must thank MS for the nail in that coffin, too: they can't
be satisfied with just a Lean broken by design, they must own the
whole compartment: only poisoned meatballs for the public...

;
-Julio

Mild Shock schrieb:

Corr.: Small typo in the number
expansion itself, should read:

10/81 = 0.(123456790) = 0.12345679(012345679)

Mild Shock schrieb:

Hi,

Now somebody was so friendly to spear head
a new Don Quixote attempt in fighting the
windmills of compare/3. Interestingly my

favorite counter example still goes through:

?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, X, Y).
X = X-0-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (<).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, Z, Y).
H = H-9-7-6-5-4-3-2-1-0,
Z = H-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (>).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X =
X-0-9-7-6-5-4-3-2-1,
    compare_with_stack(C, Z, X).
H = H-9-7-6-5-4-3-2-1-0,
Z = X, X = X-0-9-7-6-5-4-3-2-1,
C = (=).

I posted it here in March 2023:

Careful with compare/3 and Brent algorithm
https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413


Its based that rational terms are indeed in
some relation to rational numbers. The above
terms are related to:

10/81 = 0.(123456790) = 0.12345679(02345679)

Bye

Mild Shock schrieb:

Hi,

That false/0 and not fail/0 is now all over the place,
I don't mean in person but for example here:

?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
false.

Is a little didactical nightmare.

Syntactic unification has mathematical axioms (1978),
to fully formalize unifcation you would need to
formalize both (=)/2 and (≠)/2 (sic!), otherwise you
rely on some negation as failure concept.

Keith L. Clark, Negation as Failure
https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11

You can realize a subset of a mixture of (=)/2
and (≠)/2 in the form of a vanilla unify Prolog
predicate using some of the meta programming
facilities of Prolog, like var/1 and having some

negation as failure reading:

/* Vanilla Unify */
unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
unify(V, T) :- var(V), !, V = T.
unify(S, W) :- var(W), !, W = S.
unify(S, T) :- functor(S, F, N), functor(T, F, N),
      S =.. [F|L], T =.. [F|R], maplist(unify, L, R).

I indeed get:

?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
false.

If the vanilla unify/2 already fails then unify
with and without subject to occurs check, will also
fail, and unify with and without ability to
handle rational terms, will also fail:

Bye

Mild Shock schrieb:

Interestingly, DCG is also affect. Here a
DCG take of an append app/3, it has the 2nd
and 3rd argument swapped:

?- [user].
app([]) --> [].
app([X|Y]) --> [X], app(Y).
^D

Looks like an append, taking the argument swap
into account, the A=B is redundant, could
be optimized away:

/* SWI-Prolog 9.3.25 */
?- listing(app/3).
app([], A, B) :-
     A=B.
app([A|B], [A|C], D) :-
     app(B, C, D).

And works like an append, again taking the
argument swap into account:

?- app([1],X,[2,3]).
X = [1, 2, 3].

Now the multi-argument indexing test, still
taking the argument swap into account;

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 3]: app(X, [1], Y).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

Versus:

/* SWI-Prolog 9.3.25 */
?- app(X, [1], Y).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

A 2020 study analyzing 2,927 GitHub projects found
that many repositories quickly become unmaintained.
This implies that the majority of projects don’t
sustain long-term active development.

Another study reported 46% of repositories inactive
for at least six months, and only 13% active in the
last month, showing low ongoing engagement
across most repos.

Because millions of repos exist on GitHub, and
large portions are abandoned, inactive, or minimal
“toy” projects, the fraction of repositories that are
well-maintained, collaborative, and used in
production contexts is low—roughly estimated
to be around 1–2%.

The caravan moves forth, leaving behind the
occasional turd perfectly captures GitHub. Rename
GitHub, to TurdPit, and make Amber Heard their CEO.

Bye

Mild Shock schrieb:

Hi,

1. Everybody’s a programmer now
   The barrier to entry dropped dramatically — you can
   become a "developer" with a few online tutorials
   and a GitHub account.

2. Everybody’s an academic now
   Academia expanded, but standards often fell. In
   some places, it's publish or perish, so paper
   mills and fake research flourish.

3. Signal Collapse ↔ Systemic Uncertainty
   Credentials lose meaning, No reliable markers of
   skill, Fragile systems built on shallow knowledge

4. Signal Collapse ↔ Systemic Uncertainty
   Quantity overwhelms quality, Important truths get
   buried, Bad signals drown good ones

Etc..

Bye

Mild Shock schrieb:

Hi,

Having 2544 issues is probably a bad sign.
I find this many issues here:

https://github.com/rocq-prover/rocq/issues

Mostlikely 90% of the issues can be move to
the new discussion feature of GitHub.

LoL

Bye

P.S.: Same holds for Scryer Prolog with 406 issues.

Mild Shock schrieb:

Hi,

Maybe AGI should take over proving.
Just take the humans out of the loop
of any programming, it leads to nowhere.

Bye

Julio Di Egidio schrieb:

But we must thank MS for the nail in that coffin, too: they can't
be satisfied with just a Lean broken by design, they must own the
whole compartment: only poisoned meatballs for the public...

;
-Julio

Mild Shock schrieb:

Corr.: Small typo in the number
expansion itself, should read:

10/81 = 0.(123456790) = 0.12345679(012345679)

Mild Shock schrieb:

Hi,

Now somebody was so friendly to spear head
a new Don Quixote attempt in fighting the
windmills of compare/3. Interestingly my

favorite counter example still goes through:

?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, X, Y).
X = X-0-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (<).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1, >>>>>     compare_with_stack(C, Z, Y).
H = H-9-7-6-5-4-3-2-1-0,
Z = H-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (>).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X =
X-0-9-7-6-5-4-3-2-1,
    compare_with_stack(C, Z, X).
H = H-9-7-6-5-4-3-2-1-0,
Z = X, X = X-0-9-7-6-5-4-3-2-1,
C = (=).

I posted it here in March 2023:

Careful with compare/3 and Brent algorithm
https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413


Its based that rational terms are indeed in
some relation to rational numbers. The above
terms are related to:

10/81 = 0.(123456790) = 0.12345679(02345679)

Bye

Mild Shock schrieb:

Hi,

That false/0 and not fail/0 is now all over the place,
I don't mean in person but for example here:

?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
false.

Is a little didactical nightmare.

Syntactic unification has mathematical axioms (1978),
to fully formalize unifcation you would need to
formalize both (=)/2 and (≠)/2 (sic!), otherwise you
rely on some negation as failure concept.

Keith L. Clark, Negation as Failure
https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11

You can realize a subset of a mixture of (=)/2
and (≠)/2 in the form of a vanilla unify Prolog
predicate using some of the meta programming
facilities of Prolog, like var/1 and having some

negation as failure reading:

/* Vanilla Unify */
unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
unify(V, T) :- var(V), !, V = T.
unify(S, W) :- var(W), !, W = S.
unify(S, T) :- functor(S, F, N), functor(T, F, N),
      S =.. [F|L], T =.. [F|R], maplist(unify, L, R).

I indeed get:

?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
false.

If the vanilla unify/2 already fails then unify
with and without subject to occurs check, will also
fail, and unify with and without ability to
handle rational terms, will also fail:

Bye

Mild Shock schrieb:

Interestingly, DCG is also affect. Here a
DCG take of an append app/3, it has the 2nd
and 3rd argument swapped:

?- [user].
app([]) --> [].
app([X|Y]) --> [X], app(Y).
^D

Looks like an append, taking the argument swap
into account, the A=B is redundant, could
be optimized away:

/* SWI-Prolog 9.3.25 */
?- listing(app/3).
app([], A, B) :-
     A=B.
app([A|B], [A|C], D) :-
     app(B, C, D).

And works like an append, again taking the
argument swap into account:

?- app([1],X,[2,3]).
X = [1, 2, 3].

Now the multi-argument indexing test, still
taking the argument swap into account;

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 3]: app(X, [1], Y).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

Versus:

/* SWI-Prolog 9.3.25 */
?- app(X, [1], Y).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

I checked that your examples are not counter
examples for my compare_with_stack/3.

What makes you think the values I show, X, Y
and Z, are possible in a total linear ordering?
The values also break predsort/3, you can easily
verify that sort([x,y,z]) =\= sort([y,x,z]):

value(x, X) :- X = X-0-9-7-6-5-4-3-2-1.
value(y, Y) :- Y = Y-7-5-8-2-4-1.
value(z, Z) :- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1.

values(L, R) :- maplist(value, L, R).

?- values([x,y,z], A), predsort(compare_with_stack, A, B),
values([y,x,z], C), predsort(compare_with_stack, C, D),
B == D.
false.

But expectation would be sort([x,y,z]) ==
sort([y,x,z]) since sort/2 should be immune
to permutation. If this isn’t enough proof that
there is something fishy in compare_with_stack/3 ,

well then I don’t know, maybe the earth is indeed flat?

Mild Shock schrieb:

Hi,

Maybe AGI should take over proving.
Just take the humans out of the loop
of any programming, it leads to nowhere.

Bye

Julio Di Egidio schrieb:

But we must thank MS for the nail in that coffin, too: they can't
be satisfied with just a Lean broken by design, they must own the
whole compartment: only poisoned meatballs for the public...

-Julio

Mild Shock schrieb:

Corr.: Small typo in the number
expansion itself, should read:

10/81 = 0.(123456790) = 0.12345679(012345679)

Mild Shock schrieb:

Hi,

Now somebody was so friendly to spear head
a new Don Quixote attempt in fighting the
windmills of compare/3. Interestingly my

favorite counter example still goes through:

?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, X, Y).
X = X-0-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (<).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, Z, Y).
H = H-9-7-6-5-4-3-2-1-0,
Z = H-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (>).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X =
X-0-9-7-6-5-4-3-2-1,
    compare_with_stack(C, Z, X).
H = H-9-7-6-5-4-3-2-1-0,
Z = X, X = X-0-9-7-6-5-4-3-2-1,
C = (=).

I posted it here in March 2023:

Careful with compare/3 and Brent algorithm
https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413


Its based that rational terms are indeed in
some relation to rational numbers. The above
terms are related to:

10/81 = 0.(123456790) = 0.12345679(02345679)

Bye

Mild Shock schrieb:

Hi,

That false/0 and not fail/0 is now all over the place,
I don't mean in person but for example here:

?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
false.

Is a little didactical nightmare.

Syntactic unification has mathematical axioms (1978),
to fully formalize unifcation you would need to
formalize both (=)/2 and (≠)/2 (sic!), otherwise you
rely on some negation as failure concept.

Keith L. Clark, Negation as Failure
https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11

You can realize a subset of a mixture of (=)/2
and (≠)/2 in the form of a vanilla unify Prolog
predicate using some of the meta programming
facilities of Prolog, like var/1 and having some

negation as failure reading:

/* Vanilla Unify */
unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
unify(V, T) :- var(V), !, V = T.
unify(S, W) :- var(W), !, W = S.
unify(S, T) :- functor(S, F, N), functor(T, F, N),
      S =.. [F|L], T =.. [F|R], maplist(unify, L, R).

I indeed get:

?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
false.

If the vanilla unify/2 already fails then unify
with and without subject to occurs check, will also
fail, and unify with and without ability to
handle rational terms, will also fail:

Bye

Mild Shock schrieb:

Interestingly, DCG is also affect. Here a
DCG take of an append app/3, it has the 2nd
and 3rd argument swapped:

?- [user].
app([]) --> [].
app([X|Y]) --> [X], app(Y).
^D

Looks like an append, taking the argument swap
into account, the A=B is redundant, could
be optimized away:

/* SWI-Prolog 9.3.25 */
?- listing(app/3).
app([], A, B) :-
     A=B.
app([A|B], [A|C], D) :-
     app(B, C, D).

And works like an append, again taking the
argument swap into account:

?- app([1],X,[2,3]).
X = [1, 2, 3].

Now the multi-argument indexing test, still
taking the argument swap into account;

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 3]: app(X, [1], Y).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

Versus:

/* SWI-Prolog 9.3.25 */
?- app(X, [1], Y).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

The same example values also create fishy 🐟
sorting using native sorting in Scryer Prolog:

/* Scryer Prolog 0.9.4-417 */
?- values([z,x,y], A), sort(A, B),
values([x,y,z], C), sort(C, D), B == D.
false. /* fishy 🐟 */

Or using native sorting in SWI-Prolog:

/* SWI-Prolog 9.3.25 */
?- values([z,x,y], A), sort(A, B),
values([x,y,z], C), sort(C, D), B == D.
false. /* fishy 🐟 */

Bye

Mild Shock schrieb:

I checked that your examples are not counter
examples for my compare_with_stack/3.

What makes you think the values I show, X, Y
and Z, are possible in a total linear ordering?
The values also break predsort/3, you can easily
verify that sort([x,y,z]) =\= sort([y,x,z]):

value(x, X) :- X = X-0-9-7-6-5-4-3-2-1.
value(y, Y) :- Y = Y-7-5-8-2-4-1.
value(z, Z) :- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1.

values(L, R) :- maplist(value, L, R).

?- values([x,y,z], A), predsort(compare_with_stack, A, B),
   values([y,x,z], C), predsort(compare_with_stack, C, D),
   B == D.
false.

But expectation would be sort([x,y,z]) ==
sort([y,x,z]) since sort/2 should be immune
to permutation. If this isn’t enough proof that
there is something fishy in compare_with_stack/3 ,

well then I don’t know, maybe the earth is indeed flat?

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

You can answer such questions
to the negative via Fuzzy Testing:

However such relation induced above is transitive ?

Typical counter example, showing
the native compare/3 is not transitive:

/* SWI-Prolog 9.3.25 */
?- repeat, fuzzy(X), fuzzy(Y), compare(<,X,Y), fuzzy(Z),
compare(<,Y,Z), compare(>,X,Z).
X = f(f(f(X, 1), 1), 1),
Y = f(f(Y, 1), 0),
Z = f(f(f(Z, 1), 0), 1) .
Etc..

Works also for Trealla Prolog, so I
assume compare_expensive/3 also fails:

/* Trealla Prolog 2.78.5 */
?- repeat, fuzzy(X), fuzzy(Y), compare(<,X,Y), fuzzy(Z),
compare(<,Y,Z), compare(>,X,Z).
X = f(f(f(...,0),0),1), Y = f(f(...,1),0), Z = f(f(...,0),1)
; ... .
Etc..

In essence, my nasty fuzzer uses
variants of Matt Carlsons example.

P.S.: From a logic viewpoint you could view
Fuzzy Testing as a form of randomized model
checking. A little famous Fuzzy Tester was Sandsifter:

"The tool discovered undocumented instructions
in all major processors, shared bugs in nearly
every major assembler and disassembler, flaws in
enterprise hypervisors, and critical x86 hardware" https://github.com/xoreaxeaxeax/sandsifter/blob/master/references/domas_breaking_the_x86_isa_wp.pdf

So we are essentially all using Trojan Horses 🐎 daily?

Mild Shock schrieb:

Hi,

The same example values also create fishy 🐟
sorting using native sorting in Scryer Prolog:

/* Scryer Prolog 0.9.4-417 */
?- values([z,x,y], A), sort(A, B),
   values([x,y,z], C), sort(C, D), B == D.
   false. /* fishy 🐟 */

Or using native sorting in SWI-Prolog:

/* SWI-Prolog 9.3.25 */
?- values([z,x,y], A), sort(A, B),
   values([x,y,z], C), sort(C, D), B == D.
false. /* fishy 🐟 */

Bye

Mild Shock schrieb:

I checked that your examples are not counter
examples for my compare_with_stack/3.

What makes you think the values I show, X, Y
and Z, are possible in a total linear ordering?
The values also break predsort/3, you can easily
verify that sort([x,y,z]) =\= sort([y,x,z]):

value(x, X) :- X = X-0-9-7-6-5-4-3-2-1.
value(y, Y) :- Y = Y-7-5-8-2-4-1.
value(z, Z) :- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1.

values(L, R) :- maplist(value, L, R).

?- values([x,y,z], A), predsort(compare_with_stack, A, B),
    values([y,x,z], C), predsort(compare_with_stack, C, D),
    B == D.
false.

But expectation would be sort([x,y,z]) ==
sort([y,x,z]) since sort/2 should be immune
to permutation. If this isn’t enough proof that
there is something fishy in compare_with_stack/3 ,

well then I don’t know, maybe the earth is indeed flat?

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

Create a ChatGPT for cyclic terms? It seems
that the SWI-Prolog discourse contains a lot
of recent exploration of about cyclic terms.
Yet humans don’t remember them,

or are too lazy to recall them, look them
up again. Maybe to offload some of the cognitive
load and have a easier way forward, one might
use GPT builder and

create a cyclic term assistant. One could
then ask the artificial intelligece (AI) for
the following things:

- Automated Testing:
please perform some monkey testing
on my news compare/3 idea

- Automated Proving:
please suggest a proof for my newest
lemma about compare/3

- Code Refactor:
please refactor my code, I would like to
use (==)/2 instead of same_time/2

- Auto Comment:
please auto comment my code, I was too
lazy to write comments

- What else?
ChatGPT itself gave me a list when I ask
what will be between now and AGI. Could
look it up, as a few interesting items as well
mainly targeting automated summarizing ideas.

Is SWI-Prolog discourse part of the SWI-Prolog
assistant building process. Its less a static
resource, has ongoing discussions. Needs periodic
retraining of the AI.

Also the above vision includes some scenarios
where the Assistant would be better integrated
into an IDE, but these Assistants have usually
more expensive price plans.

Will this IDE be XPCE, who knows?

Mild Shock schrieb:

I checked that your examples are not counter
examples for my compare_with_stack/3.

What makes you think the values I show, X, Y
and Z, are possible in a total linear ordering?
The values also break predsort/3, you can easily
verify that sort([x,y,z]) =\= sort([y,x,z]):

value(x, X) :- X = X-0-9-7-6-5-4-3-2-1.
value(y, Y) :- Y = Y-7-5-8-2-4-1.
value(z, Z) :- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1.

values(L, R) :- maplist(value, L, R).

?- values([x,y,z], A), predsort(compare_with_stack, A, B),
   values([y,x,z], C), predsort(compare_with_stack, C, D),
   B == D.
false.

But expectation would be sort([x,y,z]) ==
sort([y,x,z]) since sort/2 should be immune
to permutation. If this isn’t enough proof that
there is something fishy in compare_with_stack/3 ,

well then I don’t know, maybe the earth is indeed flat?

Mild Shock schrieb:

Hi,

Maybe AGI should take over proving.
Just take the humans out of the loop
of any programming, it leads to nowhere.

Bye

Julio Di Egidio schrieb:

But we must thank MS for the nail in that coffin, too: they can't
be satisfied with just a Lean broken by design, they must own the
whole compartment: only poisoned meatballs for the public...

;
-Julio

Mild Shock schrieb:

Corr.: Small typo in the number
expansion itself, should read:

10/81 = 0.(123456790) = 0.12345679(012345679)

Mild Shock schrieb:

Hi,

Now somebody was so friendly to spear head
a new Don Quixote attempt in fighting the
windmills of compare/3. Interestingly my

favorite counter example still goes through:

?- X = X-0-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, X, Y).
X = X-0-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (<).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, Y = Y-7-5-8-2-4-1,
    compare_with_stack(C, Z, Y).
H = H-9-7-6-5-4-3-2-1-0,
Z = H-9-7-6-5-4-3-2-1,
Y = Y-7-5-8-2-4-1,
C = (>).

?- H = H-9-7-6-5-4-3-2-1-0, Z = H-9-7-6-5-4-3-2-1, X =
X-0-9-7-6-5-4-3-2-1,
    compare_with_stack(C, Z, X).
H = H-9-7-6-5-4-3-2-1-0,
Z = X, X = X-0-9-7-6-5-4-3-2-1,
C = (=).

I posted it here in March 2023:

Careful with compare/3 and Brent algorithm
https://swi-prolog.discourse.group/t/careful-with-compare-3-and-brent-algorithm/6413


Its based that rational terms are indeed in
some relation to rational numbers. The above
terms are related to:

10/81 = 0.(123456790) = 0.12345679(02345679)

Bye

Mild Shock schrieb:

Hi,

That false/0 and not fail/0 is now all over the place,
I don't mean in person but for example here:

?- X=f(f(X), X), Y=f(Y, f(Y)), X = Y.
false.

Is a little didactical nightmare.

Syntactic unification has mathematical axioms (1978),
to fully formalize unifcation you would need to
formalize both (=)/2 and (≠)/2 (sic!), otherwise you
rely on some negation as failure concept.

Keith L. Clark, Negation as Failure
https://link.springer.com/chapter/10.1007/978-1-4684-3384-5_11

You can realize a subset of a mixture of (=)/2
and (≠)/2 in the form of a vanilla unify Prolog
predicate using some of the meta programming
facilities of Prolog, like var/1 and having some

negation as failure reading:

/* Vanilla Unify */
unify(V, W) :- var(V), var(W), !, (V \== W -> V = W; true).
unify(V, T) :- var(V), !, V = T.
unify(S, W) :- var(W), !, W = S.
unify(S, T) :- functor(S, F, N), functor(T, F, N),
      S =.. [F|L], T =.. [F|R], maplist(unify, L, R).

I indeed get:

?- X=f(f(X), X), Y=f(Y, f(Y)), unify(X,Y).
false.

If the vanilla unify/2 already fails then unify
with and without subject to occurs check, will also
fail, and unify with and without ability to
handle rational terms, will also fail:

Bye

Mild Shock schrieb:

Interestingly, DCG is also affect. Here a
DCG take of an append app/3, it has the 2nd
and 3rd argument swapped:

?- [user].
app([]) --> [].
app([X|Y]) --> [X], app(Y).
^D

Looks like an append, taking the argument swap
into account, the A=B is redundant, could
be optimized away:

/* SWI-Prolog 9.3.25 */
?- listing(app/3).
app([], A, B) :-
     A=B.
app([A|B], [A|C], D) :-
     app(B, C, D).

And works like an append, again taking the
argument swap into account:

?- app([1],X,[2,3]).
X = [1, 2, 3].

Now the multi-argument indexing test, still
taking the argument swap into account;

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 3]: app(X, [1], Y).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

Versus:

/* SWI-Prolog 9.3.25 */
?- app(X, [1], Y).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

Mild Shock schrieb:

I am currently doing a re-evaluation of an old
Prolog system, checking what features I could adopt.
This is unlike the current trend where people have
turned their focus on GUIs, like XPCE,

or a are stuck in an endless loop of parser
problems, like in Trealla. But I would nevertheless
share my finding. Take this simple example of
a list append:

app([], X, X).
app([X|Y], Z, [X|T]) :- app(Y, Z, T).

ECLiPSe Prolog gives me, only one redo question
in the top-level:

/* ECLiPSe Prolog 7.1beta #13 */
[eclipse 2]: app(X,Y,[1]).

X = []
Y = [1]
Yes (0.00s cpu, solution 1, maybe more) ? ;

X = [1]
Y = []
Yes (0.00s cpu, solution 2)

In SWI-Prolog I find, two redo questions
in the top.level:

/* SWI-Prolog 9.3.25 */
?- app(X,Y,[1]).
X = [],
Y = [1] ;
X = [1],
Y = [] ;
false.

I know SWI-Prolog handles lists differently
than other Prolog terms during indexing. Could
this be the reason? Or maybe that the call is
not “hot” enough, so it doesn’t get JIT-ed.

ECLiPSe Prolog does it on the very first call,
and I assume its due to a kind of index on
the 3rd argument.

--- Synchronet 3.21a-Linux NewsLink 1.2

From Newsgroup: comp.lang.prolog

Hi,

What you are adressing here, in purely
symbolic form, without some helpful natural
language rephrasing:

Let (H, <) be the standard total oder an the
Prolog finite terms. Let R be the set of rational
term. H c R. Then there is total order
extention (R, <') of (H, <).

Is the problem of a compare/3 for rational trees,
that is a extension of the compare/3 for finite aka
acyclic terms with the submodel property. This is
quite possible, for example representation

based compare/3 that uses a collation key:

S @<' T :<=> rep(S) @< rep(T)

It has trivially acyclic comparison as a submodel,
when rep(S) = S for acyclic terms S. The inverse
rep^-1 itself is the homomorphism, its even an
embedding, since identity would be injective.

You might even forget about the plot, and endlessly
go down the rabbit hole of mathematics, and write a
100 pages paper, and prove Fermat’s Last Theorem
in passing again.

I can only assume mathematics currently hates
computer science because of AI.

Bye

Mild Shock schrieb:

Hi,

Create a ChatGPT for cyclic terms? It seems
that the SWI-Prolog discourse contains a lot
of recent exploration of about cyclic terms.
Yet humans don’t remember them,

or are too lazy to recall them, look them
up again. Maybe to offload some of the cognitive
load and have a easier way forward, one might
use GPT builder and

create a cyclic term assistant. One could
then ask the artificial intelligece (AI) for
the following things:

- Automated Testing:
  please perform some monkey testing
  on my news compare/3 idea

- Automated Proving:
  please suggest a proof for my newest
  lemma about compare/3

- Code Refactor:
  please refactor my code, I would like to
  use (==)/2 instead of same_time/2

- Auto Comment:
  please auto comment my code, I was too
  lazy to write comments

- What else?
  ChatGPT itself gave me a list when I ask
  what will be between now and AGI. Could
  look it up, as a few interesting items as well
  mainly targeting automated summarizing ideas.

Is SWI-Prolog discourse part of the SWI-Prolog
assistant building process. Its less a static
resource, has ongoing discussions. Needs periodic
retraining of the AI.

Also the above vision includes some scenarios
where the Assistant would be better integrated
into an IDE, but these Assistants have usually
more expensive price plans.

Will this IDE be XPCE, who knows?

--- Synchronet 3.21a-Linux NewsLink 1.2