Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!noose.ecn.purdue.edu!samsung!cs.utexas.edu!usc!randvax!narain
From: narain@randvax.UUCP (Sanjai Narain)
Newsgroups: comp.lang.prolog
Subject: Re: Compiling away bagof
Message-ID: <2572@randvax.UUCP>
Date: 4 Jun 90 19:00:32 GMT
References: <2567@randvax.UUCP> <3129@goanna.cs.rmit.oz.au>
Organization: Rand Corp., Santa Monica, Ca.
Lines: 38

In article <3129@goanna.cs.rmit.oz.au>, ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) writes:
> 
> Whew!  Had me worried for a minute there, but it _is_ in the book!
> 

Nicht verstanden.

> It isn't clear to me why bagof/3 is being used here.

Efficiency.  I quote from the Quintus Prolog manual (v. 2.5, p. 213) "this
relaxation (that lists are not ordered) saves considerable time and space
in execution".

Merging of sorted lists is not done.  Each item in the list returned by
bagof is merged into a leftist tree.  Thus, the overhead of sorting does
not appear to be necessary.

> (1) We don't need the restriction to A1,...,Am,T being variables in

Perhaps not.  It is there just to keep the compiler simple.

> 
>     Each L_{i}\L_{i+1} is a list difference pair.  Assuming a Prolog
>     compiler that open-codes if->then;else (as they all should...) this
>     also avoids the overhead of building a copy of each B_i and passing
>     through call/1.

This is a good suggestion, and I will try to incorporate it.

> 	cond_1(Body, Template, Events) :-
> 		findall(Template, Body, Events).	/* CORRECTED */

Thanks again.

> "A 7th class of programs, correct in every way, is believed to exist by a
> few computer scientists.  However, no example could be found to include here."

Nicht verstanden.