Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mcvax!tuvie!brock
From: brock@tuvie (Inst.f.Prakt.Info 1802)
Newsgroups: comp.lang.prolog
Subject: Re: Committed Choice
Keywords: cut if-then-else Garbage on the stacks
Message-ID: <678@tuvie>
Date: 9 Apr 89 12:12:18 GMT
References: <11500012@hpldola.HP.COM> <733@gould.doc.ic.ac.uk> <18798@adm.BRL.MIL> <192@aucsv.UUCP> <751@gould.doc.ic.ac.uk> <674@tuvie> <1717@etive.ed.ac.uk>
Reply-To: ulrich@vip.UUCP  (Ulrich Neumerkel)
Organization: Technical University of Vienna, EDP-Center
Lines: 22

In article <1717@etive.ed.ac.uk> jha@lfcs.ed.ac.uk (Jamie Andrews) writes:
>In article <674@tuvie> ulrich@vip.UUCP (Ulrich Neumerkel) writes:
>>blam(0,[]).
>>blam(N,[L|L]) :- N > 0, M is N - 1, blam(M,L).
>>..., blam(32,L), assert(little_fact(L)),...
>     I think most Prolog implementations would do this sensibly,
>representing this as 32 cons cells with both pointers pointing
>to the next element on the list, and the last cell pointing to
>the null list.  There seems to be no reason for copying at all
>-- [L|L] creates one cons cell.  Or am I missing something?

This is true for blam/2 but it is not evident for assert/1. Chris Moss
question was about possible overheads of loops which use assert/1 to
save the state of computation. When assert/1-ing this highly shared 
structure most systems will copy it into the database, flatting it. 
You can estimate the effects of copying such structures with: 

same([],[]).
same([HX|LX],[HY|LY]) :- same(HX,HY), same(LX,LY).
..., blam(N,L), same(L,K), something(K),...

Ulrich Neumerkel (ulrich@vip.UUCP UUCP: ...!mcvax!tuvie!vip!ulrich)