Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site allegra.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!dep
From: dep@allegra.UUCP (Dewayne Perry)
Newsgroups: net.lang.prolog
Subject: Re: Making Recursion Affordable in Prolog ?
Message-ID: <5932@allegra.UUCP>
Date: Wed, 19-Mar-86 07:53:39 EST
Article-I.D.: allegra.5932
Posted: Wed Mar 19 07:53:39 1986
Date-Received: Fri, 21-Mar-86 05:18:17 EST
References: <2935@sunybcs.UUCP> <11628@watnot.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 45
Keywords: Recursion and Stack Overflow

<>
I had a similar problem. I have written a prolog program to
explore the problems of creating and maintaining a very large
data base (using my record collection of 1500 records as
an example, with full information about composers, peerformers,
and pieces performed).  With about one quarter of the records entered
I encountered the stack overflow problem and started extending
the stacks and other data structures.  But of course as the
data base goot bigger, the stacks had to be enlarged as well -
a rather hopeless task.  My solution to the problem is as
follows (using the side-effect aspects of prolog):

I had a main program something like

	getlist(L1),
	sort(L1,L2),
	putindb(L2),
	processdblist,
	...

the putindb goes like this:

	putindb([]).
	putindb([H|T]) :-
		assert( something(H) ),     or maybe assertz
		putindb(T),
		!.

then processdblist is

	processdblist :-
		something(H)
		# process(H),
		fail,

	processdblist.

the database has things in the order desired and you process each 
member of the original list in the desired order.  The # operator
means "succeed only once - unbind on backtracking" (a very nice
operator to bring a bit of sanity to loops in prolog).  The stack
problem has gone away because you dont hve to keep all the previous
environments around in case you unwind to them while backtracking.

Dewayne