@MSGID:
<78d37990-4dbf-45a7-b48e-b70622588d11n@googlegroups.com> 7e97073c
@REPLY:
<23514d93-4a65-4c49-a611-947966f9e089n@googlegroups.com> 03704830
@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>
@RFC-Message-ID:
<78d37990-4dbf-45a7-b48e-b70622588d11n@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
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