@MSGID:
<947c613f-6bd6-4d5b-9802-44c415c19a4dn@googlegroups.com> 3fe33a17
@REPLY: <C8JKvH.GC1@athena.cs.uga.edu> e6a81fca
@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>
@RFC-Message-ID:
<947c613f-6bd6-4d5b-9802-44c415c19a4dn@googlegroups.com>
@TZUTC: -0700
@PID: G2/1.0
@TID: FIDOGATE-5.12-ge4e8b94
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