I guess it doesn't have term_singletons/2 in it, right?
Its pretty difficult to implement, even Ulrich Neumerkel
doesn't know a linear algorithm for this:

/* SWI-Prolog 9.1.16 */
bomb(0, 1) :- !.
bomb(N, (X+X)) :- M is N-1, bomb(M, X)

?- between(23,27,N), bomb(N,X),
time(term_singletons(X,_)), fail; true.
% -1 inferences, 0.078 CPU in 0.074 seconds (106% CPU, -13 Lips)
% -1 inferences, 0.141 CPU in 0.153 seconds (92% CPU, -7 Lips)
% -1 inferences, 0.328 CPU in 0.322 seconds (102% CPU, -3 Lips)
% -1 inferences, 0.672 CPU in 0.667 seconds (101% CPU, -1 Lips)
% -1 inferences, 1.344 CPU in 1.350 seconds (100% CPU, -1 Lips)
true.

I got an idea with my variable spines, if they would have
a singleton marking itself. If you have a spine, i.e. the
the variables of a term before instantiation, and if you

have singleton information in this spine already, I guess
you only to visit the singletons in the spine, to collect the
singletons. But maybe its too late to experiment with such

a solution. Also spines, which are available in formerly Jekejeke
Prolog, and can be already determined at compile time,
didn't make it into Dogelog Player. So maybe another solution?

Michael Covington schrieb am Sonntag, 13. Juni 1993 um 06:09:17 UTC+2:
> Below is a LaTeX document that will eventually be an appendix to

Also singleton information is useful to optimize away
the occurs check. I did some experiments in the past and
there also papers which communicate these ideas.

Until I discovered a way to do some occurs check optimization
based on another idea, completely dynamical at runtime,
without some compiletime analysis, which is now available in

formerly Jekejeke Prolog. But again, none of this made
it into Dogelog Player, which has only a traditional very
basic unify_with_occurs_check/2 built-in, but no

occurs check flag at all that would influence (=)/2.

Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:17:19 UTC+2:
> I guess it doesn't have term_singletons/2 in it, right?
> Its pretty difficult to implement, even Ulrich Neumerkel
> doesn't know a linear algorithm for this:
>
> /* SWI-Prolog 9.1.16 */
> bomb(0, 1) :- !.
> bomb(N, (X+X)) :- M is N-1, bomb(M, X)
>
> ?- between(23,27,N), bomb(N,X),
> time(term_singletons(X,_)), fail; true.
> % -1 inferences, 0.078 CPU in 0.074 seconds (106% CPU, -13 Lips)
> % -1 inferences, 0.141 CPU in 0.153 seconds (92% CPU, -7 Lips)
> % -1 inferences, 0.328 CPU in 0.322 seconds (102% CPU, -3 Lips)
> % -1 inferences, 0.672 CPU in 0.667 seconds (101% CPU, -1 Lips)
> % -1 inferences, 1.344 CPU in 1.350 seconds (100% CPU, -1 Lips)
> true.
>
> I got an idea with my variable spines, if they would have
> a singleton marking itself. If you have a spine, i.e. the
> the variables of a term before instantiation, and if you
>
> have singleton information in this spine already, I guess
> you only to visit the singletons in the spine, to collect the
> singletons. But maybe its too late to experiment with such
>
> a solution. Also spines, which are available in formerly Jekejeke
> Prolog, and can be already determined at compile time,
> didn't make it into Dogelog Player. So maybe another solution?
>
> Michael Covington schrieb am Sonntag, 13. Juni 1993 um 06:09:17 UTC+2:
> > Below is a LaTeX document that will eventually be an appendix to

Woa! Ulrich Neumerkel is really lost. Its shows me again:
"Error 404, brain not found". Is he really asking:

More and more Prolog systems: Which systems?
Which three other Prolog systems?

For a start:

https://www.swi-prolog.org/pldoc/man?predicate=term_singletons/2
https://github.com/trealla-prolog/trealla

Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:23:45 UTC+2:
> Also singleton information is useful to optimize away
> the occurs check. I did some experiments in the past and
> there also papers which communicate these ideas.
>
> Until I discovered a way to do some occurs check optimization
> based on another idea, completely dynamical at runtime,
> without some compiletime analysis, which is now available in
>
> formerly Jekejeke Prolog. But again, none of this made
> it into Dogelog Player, which has only a traditional very
> basic unify_with_occurs_check/2 built-in, but no
>
> occurs check flag at all that would influence (=)/2.
> Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:17:19 UTC+2:
> > I guess it doesn't have term_singletons/2 in it, right?
> > Its pretty difficult to implement, even Ulrich Neumerkel
> > doesn't know a linear algorithm for this:
> >
> > /* SWI-Prolog 9.1.16 */
> > bomb(0, 1) :- !.
> > bomb(N, (X+X)) :- M is N-1, bomb(M, X)
> >
> > ?- between(23,27,N), bomb(N,X),
> > time(term_singletons(X,_)), fail; true.
> > % -1 inferences, 0.078 CPU in 0.074 seconds (106% CPU, -13 Lips)
> > % -1 inferences, 0.141 CPU in 0.153 seconds (92% CPU, -7 Lips)
> > % -1 inferences, 0.328 CPU in 0.322 seconds (102% CPU, -3 Lips)
> > % -1 inferences, 0.672 CPU in 0.667 seconds (101% CPU, -1 Lips)
> > % -1 inferences, 1.344 CPU in 1.350 seconds (100% CPU, -1 Lips)
> > true.
> >
> > I got an idea with my variable spines, if they would have
> > a singleton marking itself. If you have a spine, i.e. the
> > the variables of a term before instantiation, and if you
> >
> > have singleton information in this spine already, I guess
> > you only to visit the singletons in the spine, to collect the
> > singletons. But maybe its too late to experiment with such
> >
> > a solution. Also spines, which are available in formerly Jekejeke
> > Prolog, and can be already determined at compile time,
> > didn't make it into Dogelog Player. So maybe another solution?
> >
> > Michael Covington schrieb am Sonntag, 13. Juni 1993 um 06:09:17 UTC+2:
> > > Below is a LaTeX document that will eventually be an appendix to

But this is a genious test case:

marquee(L,M) :-
append(L,R,LD),
append(R,M,LD).

I was rather thinking about:

marquee2(L,M) :-
repeat,
append(A,B,L),
append(B,A,M).

marquee2/2 obviously can run indefinitely. But can your Prolog
system run marquee/2 also indefinitely, like here:

?- marquee("prolog", _), fail; true.

Mild Shock schrieb am Freitag, 29. September 2023 um 09:15:39 UTC+2:
> Woa! Ulrich Neumerkel is really lost. Its shows me again:
> "Error 404, brain not found". Is he really asking:
>
> More and more Prolog systems: Which systems?
> Which three other Prolog systems?
>
> For a start:
>
> https://www.swi-prolog.org/pldoc/man?predicate=term_singletons/2
> https://github.com/trealla-prolog/trealla
> Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:23:45 UTC+2:
> > Also singleton information is useful to optimize away
> > the occurs check. I did some experiments in the past and
> > there also papers which communicate these ideas.
> >
> > Until I discovered a way to do some occurs check optimization
> > based on another idea, completely dynamical at runtime,
> > without some compiletime analysis, which is now available in
> >
> > formerly Jekejeke Prolog. But again, none of this made
> > it into Dogelog Player, which has only a traditional very
> > basic unify_with_occurs_check/2 built-in, but no
> >
> > occurs check flag at all that would influence (=)/2.
> > Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:17:19 UTC+2:
> > > I guess it doesn't have term_singletons/2 in it, right?
> > > Its pretty difficult to implement, even Ulrich Neumerkel
> > > doesn't know a linear algorithm for this:
> > >
> > > /* SWI-Prolog 9.1.16 */
> > > bomb(0, 1) :- !.
> > > bomb(N, (X+X)) :- M is N-1, bomb(M, X)
> > >
> > > ?- between(23,27,N), bomb(N,X),
> > > time(term_singletons(X,_)), fail; true.
> > > % -1 inferences, 0.078 CPU in 0.074 seconds (106% CPU, -13 Lips)
> > > % -1 inferences, 0.141 CPU in 0.153 seconds (92% CPU, -7 Lips)
> > > % -1 inferences, 0.328 CPU in 0.322 seconds (102% CPU, -3 Lips)
> > > % -1 inferences, 0.672 CPU in 0.667 seconds (101% CPU, -1 Lips)
> > > % -1 inferences, 1.344 CPU in 1.350 seconds (100% CPU, -1 Lips)
> > > true.
> > >
> > > I got an idea with my variable spines, if they would have
> > > a singleton marking itself. If you have a spine, i.e. the
> > > the variables of a term before instantiation, and if you
> > >
> > > have singleton information in this spine already, I guess
> > > you only to visit the singletons in the spine, to collect the
> > > singletons. But maybe its too late to experiment with such
> > >
> > > a solution. Also spines, which are available in formerly Jekejeke
> > > Prolog, and can be already determined at compile time,
> > > didn't make it into Dogelog Player. So maybe another solution?
> > >
> > > Michael Covington schrieb am Sonntag, 13. Juni 1993 um 06:09:17 UTC+2:
> > > > Below is a LaTeX document that will eventually be an appendix to

A better test case is this query:

?- append(Y, X, [1,2,3|Y]), fail; true.

Versus this query:

test(X) :- append(Y, X, [1,2,3|Y]).
?- test(X), fail; true.

Which one runs indefinitely in a Prolog system with
good last call optimization? And why?

Mild Shock schrieb am Freitag, 29. September 2023 um 09:18:24 UTC+2:
> But this is a genious test case:
>
> marquee(L,M) :-
> append(L,R,LD),
> append(R,M,LD).
>
> I was rather thinking about:
>
> marquee2(L,M) :-
> repeat,
> append(A,B,L),
> append(B,A,M).
>
> marquee2/2 obviously can run indefinitely. But can your Prolog
> system run marquee/2 also indefinitely, like here:
>
> ?- marquee("prolog", _), fail; true.
> Mild Shock schrieb am Freitag, 29. September 2023 um 09:15:39 UTC+2:
> > Woa! Ulrich Neumerkel is really lost. Its shows me again:
> > "Error 404, brain not found". Is he really asking:
> >
> > More and more Prolog systems: Which systems?
> > Which three other Prolog systems?
> >
> > For a start:
> >
> > https://www.swi-prolog.org/pldoc/man?predicate=term_singletons/2
> > https://github.com/trealla-prolog/trealla
> > Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:23:45 UTC+2:
> > > Also singleton information is useful to optimize away
> > > the occurs check. I did some experiments in the past and
> > > there also papers which communicate these ideas.
> > >
> > > Until I discovered a way to do some occurs check optimization
> > > based on another idea, completely dynamical at runtime,
> > > without some compiletime analysis, which is now available in
> > >
> > > formerly Jekejeke Prolog. But again, none of this made
> > > it into Dogelog Player, which has only a traditional very
> > > basic unify_with_occurs_check/2 built-in, but no
> > >
> > > occurs check flag at all that would influence (=)/2.
> > > Mild Shock schrieb am Donnerstag, 28. September 2023 um 22:17:19 UTC+2:
> > > > I guess it doesn't have term_singletons/2 in it, right?
> > > > Its pretty difficult to implement, even Ulrich Neumerkel
> > > > doesn't know a linear algorithm for this:
> > > >
> > > > /* SWI-Prolog 9.1.16 */
> > > > bomb(0, 1) :- !.
> > > > bomb(N, (X+X)) :- M is N-1, bomb(M, X)
> > > >
> > > > ?- between(23,27,N), bomb(N,X),
> > > > time(term_singletons(X,_)), fail; true.
> > > > % -1 inferences, 0.078 CPU in 0.074 seconds (106% CPU, -13 Lips)
> > > > % -1 inferences, 0.141 CPU in 0.153 seconds (92% CPU, -7 Lips)
> > > > % -1 inferences, 0.328 CPU in 0.322 seconds (102% CPU, -3 Lips)
> > > > % -1 inferences, 0.672 CPU in 0.667 seconds (101% CPU, -1 Lips)
> > > > % -1 inferences, 1.344 CPU in 1.350 seconds (100% CPU, -1 Lips)
> > > > true.
> > > >
> > > > I got an idea with my variable spines, if they would have
> > > > a singleton marking itself. If you have a spine, i.e. the
> > > > the variables of a term before instantiation, and if you
> > > >
> > > > have singleton information in this spine already, I guess
> > > > you only to visit the singletons in the spine, to collect the
> > > > singletons. But maybe its too late to experiment with such
> > > >
> > > > a solution. Also spines, which are available in formerly Jekejeke
> > > > Prolog, and can be already determined at compile time,
> > > > didn't make it into Dogelog Player. So maybe another solution?
> > > >
> > > > Michael Covington schrieb am Sonntag, 13. Juni 1993 um 06:09:17 UTC+2:
> > > > > Below is a LaTeX document that will eventually be an appendix to