From: Steve Perryman
Subject: Destructors in Lisp and CLOS
Date:
Message-ID: <3296@stl.stc.co.uk>
Is there a standard destructor function in Common Lisp or CLOS ???
There is no mention of one in Sonya Keene's book on CLOS, but is there one/
going to be one (in current standards etc) ??
I have crashed my application cos it creates reams of temporary objects that
need to be destroyed after their use, and the garbage collector cannot
handle it. My lisp system has a destructor function but it is definitely
non-standard and I want to use something more standard if possible.
Thanks in advance,
Steven Perryman
(···@stl.stc.co.uk)
From: Douglas S. Rand
Subject: Re: Destructors in Lisp and CLOS
Date:
Message-ID: <116718@linus.mitre.org>
In article <····@stl.stc.co.uk>, ···@stl.stc.co.uk (Steve Perryman ) writes:
|>
|>Is there a standard destructor function in Common Lisp or CLOS ???
|>There is no mention of one in Sonya Keene's book on CLOS, but is there one/
|>going to be one (in current standards etc) ??
|>
Although this might be useful this is not a goal of CLOS. Also it is generally
antithetical to the view of the LISP world. It is the job of the GC to clean
up allocated unused storage.
|>
|>I have crashed my application cos it creates reams of temporary objects that
|>need to be destroyed after their use, and the garbage collector cannot
|>handle it. My lisp system has a destructor function but it is definitely
|>non-standard and I want to use something more standard if possible.
|>
A possible work around to your problem is to add a personal destructor function
whose job it is to place an object back on a reuse heap. You obviously need to
be careful that the object really isn't in use (this is why GC is hard
to write).
There is a generic function reinitialize-instance which might or might not help
you with cleaning the old objects. But in any case you then need to modify
make-instance (allocate-instance?) for that class to grab objects off the heap
before allocating a new one.
|>
|>Thanks in advance,
|>
|>Steven Perryman
|>(···@stl.stc.co.uk)
Douglas S. Rand
Internet: <······@mitre.org>
Snail: MITRE, Burlington Road, Bedford, MA
Disclaimer: MITRE might agree with me - then again...
Amateur Radio: KC1KJ
From: Robert Krajewski
Subject: Re: Destructors in Lisp and CLOS
Date:
Message-ID: <9862@rice-chex.ai.mit.edu>
In article <······@linus.mitre.org> ···@luke.mitre.org (Douglas S.
Rand) writes:
Although this [destructors] might be useful this is
not a goal of CLOS. Also it is generally antithetical to the view of
the LISP world. It is the job of the GC to clean >up allocated unused
storage.
Yes, but since the one of the breat benefits of Lisp is that you don't
have to write your own garbage collector, it would be nice to extend
it in ways that CLOS can exploit.
For example, an object may hold onto something that is outside the
Lisp universe, like some kind of operating system resource. There
is no way for the GC to reclaim it, but it *could* ask the object to
do so.
It's pretty clear that this kind of extension can be fraught with
peril (for example, the reclamation method better not store its object
into anything except lexical places that cannot have a lifetime beyond
the execution of the method itself), but it could be useful.
--
Robert P. Krajewski
Internet: ···@ai.mit.edu ; Lotus: ······················@crd.dnet.lotus.com
From: Douglas S. Rand
Subject: Re: Destructors in Lisp and CLOS
Date:
Message-ID: <116852@linus.mitre.org>
In article <····@rice-chex.ai.mit.edu>, ···@wheaties.ai.mit.edu (Robert
Krajewski) writes:
|>Yes, but since the one of the breat benefits of Lisp is that you don't
|>have to write your own garbage collector, it would be nice to extend
|>it in ways that CLOS can exploit.
|>
|> ... Many reasons for it being a breat bennefit
I wasn't really passing judgement on the value. Certainly it would be nice to
know that you (the object) were about to be blown away so your resources could
be handled in a reasonable fashion. I was just commenting on it not being a
goal of CLOS or ANSI-X3J13.
Douglas S. Rand
Internet: <······@mitre.org>
Snail: MITRE, Burlington Road, Bedford, MA
Disclaimer: MITRE might agree with me - then again...
Amateur Radio: KC1KJ