Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!uxc!uxc.cso.uiuc.edu!clio!wengert From: wengert@clio.las.uiuc.edu Newsgroups: comp.lang.prolog Subject: Re: existential quantification in bagof Message-ID: <16400006@clio> Date: 13 Feb 89 15:27:00 GMT References: <9150@burdvax.PRC.Unisys.COM> Lines: 48 Nf-ID: #R:burdvax.PRC.Unisys.COM:9150:clio:16400006:000:1606 Nf-From: clio.las.uiuc.edu!wengert Feb 13 09:27:00 1989 /* Written 2:18 pm Feb 6, 1989 by gerdeman@clio.las.uiuc.edu in clio:comp.lang.prolog */ On this same topic, I have noticed some peculiar features of 'findall' in TI-Prolog. I don't know whether these are standard or peculiar to Texas Instrument. First: Why does 'findall not require existential quantification at all? The manual doesn't say anything at all about this. Second: why does 'findall' change variable names? For example consider the following perverse little procedure: ?-findall(X,member(X,[Y,Z],S). X = _54 Y = _98 Z = _111 S = [209,201] At first I thought this was just an annoying quirk but then I discovered that this feature is useful for copying in the following peculiar program: copy(X,Y):- findall(Z,Z=X,[Y]). This procedure turns out to be much faster than the copy program given in Sterling and Shapiro (which uses assert and retract). I used this copy procedure in my own implementation of a PATR style parser and it sped things up by an order of magnitude. Then I discovered that this explicit copying is not necessary since any destructive procedure embedded inside of 'findall' will fail to have destructive consequences. For example 'graph_unify/3' (for DAG unification) normally binds variables in its input arguments but non_destructive_unify(A,B,A_u_B):- findall(X,graph_unify(A,B,X),A_u_B). Does anyone out there know why this works? ---- Dale Gerdemann University of Ill Dept Linguistics /* End of text from clio:comp.lang.prolog */