Subject: Re: Scheme for Unix, updated version
From: rpw3@rigden.engr.sgi.com (Rob Warnock)
Date: 1999/04/14
Newsgroups: comp.lang.scheme
Message-ID: <7f158q$2i3q1@fido.engr.sgi.com>
David Fox <d s f o x @ c o g s c i . u c s d . e d u> wrote:
+---------------
| One feature that I can't do without is the "when-unreferenced"
| directive of Scheme->C:
| 
|   (when-unreferenced pixmap (lambda (x) (pixmap_deallocate screen x)))
| 
| it specifies an action to be taken when an object is garbage
| collected.  While many things can be easily added to a Scheme
| implementation, this one pretty much has to be built-in from the
| start.  I'd be grateful to hear what implemementations have this feature.
+---------------

Quite a few of them have some form of finalization, though the names
and the exact facilities offered vary all over the place. MzScheme,
for example, offers "Will Executors" (as well as "Weak Boxes"). See:

	http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node144.htm
	http://www.cs.rice.edu/CS/PLT/packages/doc/mzscheme/node146.htm
	...
	(register-will v f [e]) registers the value v with will procedure f
	in the will executor e. When v is proven unreachable, then the
	procedure f will be called with v as its argument. The default
	value for e is the current will executor (see section 9.4.1.13)
	...

So in MzScheme, if you don't care about multiple "will executors", you
should be able to get by with simply:

	(define when-unreferenced register-will)

On the other hand, some people don't like the fact that the MzScheme &
Scheme->C form of finalization forces the dead object to be "revived"
(by being passed to the executor procedure), and they offer something
similar but without the ability to revive an object. E.g., Ken Dickey's
proposal [August 1993]:

	ftp://ftp.cs.indiana.edu/pub/scheme-repository/doc/misc/Finally.txt
	...
	The interface I use is

		(register-for-finalization <object> <thunk>)

	After the <object> has been reclaimed by the collector, the <thunk>
	is invoked.  The thunk is a procedure of no arguments and contains
	arbitrary code.  Note that the thunk cannot directly refer to the
	object or the object will never be collected!  If some state needs
	to be retained for clean up, one can arrange that both the object
	and the thunk share the state indirectly.  
	...

[The appendix to this paper contains an implementation assuming that
the underlying Scheme provides weak pairs and some kind of post-GC hook.]


-Rob

-----
Rob Warnock, 8L-855		rpw3@sgi.com
Applied Networking		http://reality.sgi.com/rpw3/
Silicon Graphics, Inc.		Phone: 650-933-1673
2011 N. Shoreline Blvd.		FAX: 650-933-0511
Mountain View, CA  94043	PP-ASEL-IA