@MSGID:
<fa127b24-b1b4-4a03-9be0-ac1c1018bf78n@googlegroups.com> 101afc52
@REPLY:
<78d37990-4dbf-45a7-b48e-b70622588d11n@googlegroups.com> 7e97073c
@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>
@RFC-Message-ID:
<fa127b24-b1b4-4a03-9be0-ac1c1018bf78n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
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