I have a question regarding CLOS objects created with make-instance.
Is it possible in any way to 'destroy' such an object.  For example,
to say (delete-instance ...) or such that would effectively
make that object disappear in a meaningful way (for example, all
references to that object will refer to nil)

A second question (a follow-up on an earlier post) is regarding
side-effects.  I've decided to make a package (say :foo) that
has interned only what I believe to be side-effect free functions.
Is there someway that I can ensure a form in, say package :goo,
to use only those functions:

(let ((*package* (find-package 'foo)))
   ... stuff ...
    ))

in stuff use of :: should not be allowed, for example.

Usually the garbage collector takes care of freeing
the space. Some Lisp implementations allow "finalization".
So the Lisp system calls a function before the GC "destroys"
the object. This is sometimes needed in case the object
points to foreign data structures that needs to be freed, too.

Note:

(funcall (symbol-function (find-symbol "MY-SECRET-FUNCTION"
                                       "MY-SECRET-PACKAGE"))
         42)

This is naturally done as a generic function with methods for various
types -- the method for cons just recurses on the car & cdr, the
method for symbol does the interesting bit and so on.  You need to
have a method on T which fails the form so you reject anything you
don't accept.  You need to write methods for any compound objects you
plan to accept (arrays perhaps) which walk into them.  You need an
occurs check to deal with circular structure.

  I'll assume that you're _not_ an idiot and that it is inappropriate
  to answer your question with "you don't need this because we have a
  garbage collector in Common Lisp" as if you didn't know that.

  The problem you allude to is that of tracking down all references.
  This can't be done, so forget it.  (If you think it can, you didn't
  consider the value of "all" carefully enough, unless you actually
  are the garbage collector, but that's not what you're asking about.)

  So we don't track down any references at all.  Instead, we make the
  perfectly valid references we already have around the system point
  to the same object, but make it a different kind of object.  You can
  do that with change-class.  Except you can't turn a CLOS object into
  a system object like nil, but if all you're interested in is junking
  a bunch of data that otherwise would hang around forever because
  there might be some dangling reference somewhere you didn't think
  of, create some very empty class, (defclass nothingness () ()), and
  change instances into that class.

  Then there's the extremely valuable slot-makunbound which makes any
  references to slots of CLOS instances signal an error (or call the
  handler, to be more precise, which generally signals an error) unles
  sit has been bound anew.  This guarantees that you won't have any
  rogue referents at all.  However, this requires that you destroy
  objects that are tied to particular slots.  I find that this is
  often the case, but your mileage may vary.

| A second question (a follow-up on an earlier post) is regarding
| side-effects.  I've decided to make a package (say :foo) that
| has interned only what I believe to be side-effect free functions.
| Is there someway that I can ensure a form in, say package :goo,
| to use only those functions:
|
| (let ((*package* (find-package 'foo)))
|    ... stuff ...
|     ))
|
| in stuff use of :: should not be allowed, for example.

  This requires access to internals, and is generally not simple to
  accomplish, because intern is such a basic function.  However, if
  you are a supported Allegro CL user and promise not to use Presto,
  you can take a look at src:code;package.cl and locate intern*, then
  remove the #+notyet, and compile that one function.  After this fix,
  you get results like these:

(13) cl-user
(handler-case (intern "foobarzot" :cl)
  (excl:package-locked-error ()
    (format *debug-io* "~&~s: no can do.~%" '(intern "foobarzot" :cl))))
(intern "foobarzot" :cl): no can do.
=> nil

  The macro excl::without-package-locks allows its body forms to make
  changes to locked packages.

why do you think it is not 'needed'?  We have a simulation environment,
where, say N vehicles are spewed by some random unit, live in the
environment for a while and then disappear.  The point of the simulation
is to test a component that can interact within this environment; thus
this component is responsible for making sure its references to these
'disappearing' vehicles are maintained.

I don't see why it is not 'possible' either.  I can see that destroying
objects is not defined in ANSI CL but extensions in particular
implementations
should be possible.

Thanks,
tunc

Thanks,
Tunc

Regards,
Jochen Schmidt

With the latter, assuming an inverse function defined on the persistent ID
slot of 'truc' persistent class (sorry, couldn't resist, truc is a familiar
French word):

(with-transaction ()
 (make-instance 'truc :ID 1))
....
(with-transaction ()
 (delete-instance (find-truc 1)))

But as you can read in my other post, you could make use of
"Weak-Pointers". You wiil need special code to do the accesses to such
"weak referenced" objects, but you can then test if a object is still alive
or garbage-collected. Others mentioned very good solutions - I like the
hash-table way - similar to "weak-pointers" but with better possibility of
"freeing" the object "on command"

(defclass sim-entity ()
  ;; Slots and stuff
  )

(defclass vanished-sim-entity ()
  ())

(defun let-sim-entity-vanish (entity)
  (change-class entity 'vanished-sim-entity))

(defun valid-sim-entity-p (entity)
  (typep entity 'sim-entity))

Indeed this can be extended to leave behind information for those
referencing the now vanished entity, i.e.:

(defclass vanished-sim-entity ()
  ((reason :initarg :reason :reader vanished-sim-entity-reason)))

(defun let-sim-entity-vanish (entity &optional reason)
  #+CMU
  (progn ;; CMU CL still has pre-ANSI change-class
    (change-class entity 'vanished-sim-entity)
    (reinitialize-instance entity :reason reason))
  #-CMU
  (change-class entity 'vanished-sim-entity :reason reason))

(defun valid-sim-entity-p (entity)
  (typep entity 'sim-entity))

Regs, Pierre.

There is a longstanding set of research into a memory management scheme
known as Garbage Collection.  If you only use C++, you might not have
heard of it, but it is used by many languages of both antiquity and
modernity.

With Garbage Collection, you need not explicitly "delete" unneeded
objects; you need only unlink the objects from whatever data structures
you are using to access the vehicles. The next time the garbage
collector is invoked (where I'm being _rather_ loose about the term
"next time"), those objects that are no longer being referenced will get
"collected."

In effect, the component you are asking about _does_ exist; it is called
the Garbage Collector.  If I define an object via:
  (setf current-car (make-automobile :brand 'ford :model 'taurus :price
                                              250000))
   and then want to get rid of it, I need only do:
  (setf current-car 'something-else)

That automobile, no longer being referenced, is Fair Game for the Grim
Reaper aka the Garbage Collector.  (Of course, if I'd thrown a reference
to the car into the array "car-queue", it would be kept until the
"car-queue" reference got discarded...)

The point is that the way you delete something is to not refer to it
anymore.

1. perform some kind of `finalization' on the object when you are done
   with it.  You can do this by just defining some GF -- `delete' say,
   and defining appropriate methods.  

   This is often confused with the desire for a system-supplied
   finalization protocol, under which some GF might be called on
   object just before they are swept up by the GC.  But that's not the
   same thing at all because you have no control over when (or if)
   such a GF is called unless you are willing to specify the GC rather
   closely.  A system-supplied protocol might be useful, for instance
   to give you some hope of not leaking finite resources like file
   handles, but it *doesn't* allow you to say `I am done with this
   object now, please clean it up'.  Java has this kind of protocol, I
   kind of hope they haven't overspecified the GC to make it `more
   useful'.

2. somehow nullify all references to the object.  This is hard in
   general (and I'm not actually completely sure why you would want to
   do this) as you need complete knowledge of the system to do it, and
   only the GC has that.  One could imagine some GC extension under
   which the GC would be willing to unilaterally collect objects which
   still had references, making those references point to NIL (this
   is, I think, slightly different than the semi-standard
   wak-hashtable/weak-pointer thing, as there wouldn't be any extra
   indirection).  But this doesn't do what you seem to want because
   you don't know when, or if, it will happen without overspecifying
   the GC once again, even if it were reasonable to specify such a
   thing in the first place.

   So you have to resort to some lesser trick, either having the
   object keep a list of references to itself as I suggested, or
   (better) Erik's scheme of using change-class to make the object be
   some obviously dead thing.

There's also a non-useful thing that people often want to do:

3. Make the object `actually go away'.

So, in CL, (1) is very easy.  (2) is no harder than it is in any other
language (it's a serious pain in other words, but it's always a
serious pain to do steam memory management), and (3) is basically
impossible.  But (3) is also meaningless -- once there are no
references to the thing what does it mean for it to `go away'?  Once
you can't see it, it's gone except, perhaps, as far as the system is
concerned, and the system can look after itself: that's why you're
writing in Lisp, after all.

So, really, I'm confused about what you are trying to do.

  This is about object management, not memory management.  Grow a clue.

| That automobile, no longer being referenced, is Fair Game for the Grim
| Reaper aka the Garbage Collector.

  He's asking "how to get to the no-longer-being-referenced state?"

| The point is that the way you delete something is to not refer to it
| anymore.

  Why do you think he doesn't understand that?  He's asking about how
  to ensure that nothing refers to it anymore.  Can't you read?

| There's no problem; you need only throw away the references, and
| the automobile object will indeed get deleted.

  Will you get around to tell him how to throw away the references, or
  will you keep telling him he "need only do it"?  I'm getting the
  very distinct impression that you don't know how to get rid of the
  references and can't really help him, so you think this is about
  something you can "help" him with.  This is stupid newbie behavior.

  What is it about you guys who grew up with C++ and confuse object
  management with memory management?  Just because C++ doesn't know
  how to separate the two management tasks doesn't mean they aren't
  two separate management tasks.  If you really _understood_ what
  Garbage Collection (as you write it) is all about, you would not
  have this anal-retentive reaction to object management as if it were
  about memory.  I don't think you appreciate what the life of a
  complex object in a complex relationship with other objects really
  entails and requires of the programmer.  Garbage collection is
  great, but that doesn't mean you can drop everything on the floor
  and never have to do anything -- even though most programmers are
  exceedingly young and immature, their mom is no longer around to do
  that particular kind of magic.

  Here's a clue-giving question: When and why do we need finalization
  in a system with garbage collection?  When and why do we need
  explicit control over the destruction of certain (which?) objects,
  and when would untended garbage collection be counter-productive?

You might have functions like: add-vehicle, destroy-vehicle, get-vehicles, ...
defined for your simulation.  You would have some data structure you
are using to keep track of all your vehicles, let's say it is a hash table
(but it could be *any* data structure you think is efficient for your
problem).  Then you might keep all your vehicles in a special:

(defvar *vehicles* (make-hash-table))

(defun add-vehicle (id)
   (setf (gethash id *vehicles*) (make-instance 'vehicle :id id)))

(defun get-vehicle (id)
   (gethash id *vehicles*))

(defun destroy-vehicle (id)
   (setf (gethash id *vehicles*) nil)))

(defun get-vehicles ()
  (loop for value being the hash-value of *vehicles*
        collect value))

The contract for consumers of this code is that they don't cache the values
returned from get-vehicle and get-vehicles.

"Christopher J. Vogt" <v...@computer.org> writes:

        (make-hash-table :weak-p t)

were in the Standard..... :{

Cheers

This is where weak pointers can be helpful.  If you have a main reference
that you can easily nullify in the application, you could make all the
other references weak, so they won't keep the GC from reclaiming the
object.

I agree with you of course that you do need to make sure get picked up
at some point, unless you have really a lot of memory...  Managing
objects in Lisp is easier than C, say, but you still need to do it.

Inicidentally are there any weak-pointer implementations that are
really transparent?  Most of the ones I've seen involve some kind of
wak hashtable through which you have to indirect, or weak conses.  I
guess an adequate solution would be to be able to declare slots in
objects as weak: does anyone have that?

While it would be nifty to have the language maintain references for you (it is a
wonderful feature of the persistent AllegroStore), this seems to involve a
confusion of levels, specifically, that of the code and the model the code
implements. I am proposing that whatever you mean by vehicles disappearing, just
do a little work to let "this component" know about it...and as I suggested, the
manner in which "this component" learns of vehicle spew probably is a good place
to start thinking about how it should learn about disappearance.

Others have proposed language-level tricks which you might like, I think you are
closer to the tao if you conjure up a method #'vehicle-disappear to go along with
#'vehicle-spew.

  Really?  It can't _allow_ that, huh?  What happens if I try?

| I might want to store a particular sequence of bits in a particular
| memory location, but if I pick the wrong sequence of bits, or the
| wrong memory location, it could cause the program to crash without
| hope of recovery.

  Suppose I want this and I don't buy your line.  Are FFIs within
  "Lisp" as you define it?  Can I use functions that produce machine
  code that effectively bypass the whole security system if that's
  part of what the compiler provides?  When does it stop being "Lisp"?

| Many popular languages work this way.  Lisp does not.

  This is nonsense.  "Lisp" has no such restrictions, for any value of
  Lisp, even Common Lisp.  Any reasonable implementation will offer
  you ways to do anything you want, including using an FFI and low-
  level memory operations.  It's essential to a programming language
  to be able to manipulate hardware.

  It is essential that it isn't the _default_, but the _ability_ must
  be there, or people will use something else for that part, and they
  won't ever grow beyond it, because, you see, huge numbers of people
  who want to become programmers still think it's all about control.
  Well, it so happens that actually is, so the question is not control
  or no control, but control over _what_.  It takes most people a
  _long_ time to get the point where they realize what they really
  want to have control over.  Lisp _allows_ them to figure it out,
  because in Lisp, you don't stop at the low-level: there is no glass
  ceiling.

  Shed your misconceptions and try to think about what Lisp for really
  low-level stuff would be like.  What would you want to do at the
  very lowest level of a modern computer architecture?  What would you
  _not_ want to do at that level?

I don't think Einstein would get away with GOTOs all the time, but I
think you missed the point.  It's not that because you are Very
Intelligent or even Recognized Genius that you are allowed to use
GOTOs.  It's that if a GOTO is the best solution to your problem you
should use a GOTO.  Since this is probably rarely the case, it's
usually a good idea to think about other solutions before resorting to
GOTO.  I don't think that I have ever seen a need for a GOTO in my
programs, but if the situation would ever come up that I believe a
GOTO is the best solution, I would go ahead and use it.

The same applies to the original question.  Just saying "you're not
supposed to do that" is less than helpful.  Giving a solution and
pointing out possible down- and upsides to it is much more helpful.

| This is so sad. The advantage of the funtional paradigm is well
| understood, the advantage of hacking bits at will is well
| understood...give us a break...meanwhile the poor newbie trying to handle
| the snuffation of vehicles...ah, f*ck'm, right?

How do you know that the original question came from a newbie?

And besides, Erik has given a very helpful answer right at the start
of this thread.

--
bo...@uncommon-sense.net - <http://www.uncommon-sense.net/>

  Improve your reading comprehension and try again.

| Sh*t man, Einstein could get away with GOTOs...does that make them
| one scintilla less damnable? (Hint: no.)

  Gotos aren't damnable to begin with.  If you aren't smart enough to
  distinguish what's bad about some gotos from all gotos, goto hell.

| All the dude is talking about is good common practice, why strike
| this holier-than-thou oh-yeah?-lisp-can-do-anything pose?

  Because the "dude" claimed something that is completely false, that
  "Lisp" doesn't _allow_ something it _does_ allow, in spades.

| Yeah, fine, agreed, Lisp has access to the Evil Empire FFI so it can
| blow away Princess Leah at will.  You win.  Can we go back to
| talking about the most elegant way to snuff vehicles?  Criminey 'o
| golden...

  Get yourself committed before you hurt anyone, Kenny.  You're tilting.

| Hey, lesson #1, never tell other people what they should do.

  So shut the fuck up, moron.

All I meant was, one should code well even if one is capable of getting
bad code to work. Sorry I tripped the GOTO wire.

In this case, I am suggesting it is a Bad Thing not to be consistent:
the second component should learn about vehicles "disappearing" in a
fashion similar to that in which it learns of their spew.

Not to say the nifty hacks others proposed were not, well, nifty. They
just were not of the Tao, if you will.