@MSGID:
<262f164c-392a-4095-9326-3602a043737cn@googlegroups.com> 0bdab30e
@REPLY:
<fa127b24-b1b4-4a03-9be0-ac1c1018bf78n@googlegroups.com> 101afc52
@REPLYADDR Mild Shock <bursejan@gmail.com>
@REPLYTO 2:5075/128 Mild Shock
@CHRS: CP866 2
@RFC: 1 0
@RFC-References: <C8JKvH.GC1@athena.cs.uga.edu>
<947c613f-6bd6-4d5b-9802-44c415c19a4dn@googlegroups.com> <23514d93-4a65-4c49-a611-947966f9e089n@googlegroups.com>
<78d37990-4dbf-45a7-b48e-b70622588d11n@googlegroups.com> <fa127b24-b1b4-4a03-9be0-ac1c1018bf78n@googlegroups.com>
@RFC-Message-ID:
<262f164c-392a-4095-9326-3602a043737cn@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
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
--- G2/1.0
 * Origin: usenet.network (2:5075/128)
SEEN-BY: 5001/100 5005/49 5015/255 5019/40 5020/715
848 1042 4441 12000
SEEN-BY: 5030/49 1081 5058/104 5075/128
@PATH: 5075/128 5020/1042 4441