From p.singleton@keele.ac.uk  Thu May 18 11:54:58 2000
Received: from cmailg5.svr.pol.co.uk (cmailg5.svr.pol.co.uk [195.92.195.175])
	by swi.psy.uva.nl (8.9.3/8.9.3) with ESMTP id LAA02421
	for <prolog@swi.psy.uva.nl>; Thu, 18 May 2000 11:54:58 +0200 (MET DST)
Received: from modem4294967237.fashion.dialup.pol.co.uk ([195.92.4.187] helo=keele.ac.uk)
	by cmailg5.svr.pol.co.uk with esmtp (Exim 3.13 #0)
	id 12sN1S-0005ev-00
	for prolog@swi.psy.uva.nl; Thu, 18 May 2000 10:55:18 +0100
Message-ID: <39231E3E.4DB5498F@keele.ac.uk>
Date: Wed, 17 May 2000 23:33:34 +0100
From: Paul Singleton <p.singleton@keele.ac.uk>
Organization: SmartArts Computing Consultancy
X-Mailer: Mozilla 4.7 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: SWI Prolog <prolog@swi.psy.uva.nl>
Subject: [Fwd: Non-redundant wrappers?]
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Ulrich Neumerkel wrote:

> Paul Singleton <p.singleton@keele.ac.uk> wrote:

> ...
> >It would seem to require something like Quintus' "trail hook" to clean up
> >the (again, seemingly) unavoidable global state (asserted or recorded),
> ...

> This can be realized with call_cleanup/2, a built-in in SICStus Prolog.
> The goal call_cleanup(Goal, Cleanup) will call Cleanup (which should be
> determinate) when the execution of Goal is "finished".  I.e., on
> failure, exception, determinate success of Goal but also when cutting choices
> of Goal (!).  So Cleanup can delete the temporary database required to
> detect redundant solutions.

This is the first I've heard of call_cleanup/2, but it sounds nicer than the
"trail hook", which would only call a foreign function; whichever, something
like this would be of value to me in my efforts to interface Prolog to the
Real World in as Prolog-like a way as possible, e.g. backtracking through the
tuples of a RDBMS query's result relation without having to cache all of them
in the database first, yet being able to cut the goal without leaving a
"cursor" (or other foreign state) dangling.

Unless there's an existing way of achieving this, I'd vote for this sort of
development of SWI-Prolog in preference to unspecified performance improvements
as recently suggested.

Paul Singleton


