destroying CLOS objects
Tunc Simsek
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.
Thanks,
Tunc
Jochen Schmidt
> regards,
>
> 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)
Something like a "delete" or "free" is neither needed nor possible in
garbage-collected systems. Think of what would happen, if you would "delete"
an object that is referenced by some other object or needed in a
calculatoin somewhere! If you have problem with generating a huge amount of
short-living objects, a Common Lisp with a generational GC could help.
You can trigger the GC at several "noncritical places" hoping that the
system doesn't GC in "critical places".
Regards
Jochen
Rainer Joswig
sim...@robotics.eecs.berkeley.edu wrote:
> regards,
>
> 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)
There is nothing like this in Common Lisp. If you want
to do something like that, you have to program it
yourself. Usually an object is unnamed and does not
know about references to itself.
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.
> 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.
You would need to change the reader.
Note:
(funcall (symbol-function (find-symbol "MY-SECRET-FUNCTION"
"MY-SECRET-PACKAGE"))
42)
--
Rainer Joswig, Hamburg, Germany
Email: mailto:jos...@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Tim Bradshaw
> regards,
> 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)
I think you'd do this the same way you'd do it in, say C++: you need
to do something like keep a list of all objects that refer to the
object in question, and at delete time walk down it and make all the
refs be to nil (you need to keep a method' to make the reference be
nil too). Alternative approaches would be to make all references be
indirect through (say) a hash table, and then replace the object in
the hashtable by nil, or finding a solution which doesn't involve
doing this. (Note that in, say C++, deleting an object doesn't make
people who refer to it refer to nil (or the C++ equivalent), it leaves
them referring to completely random bits of memory which used to hold
the object, unless you implement a scheme like the above).
> 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:
yes, that is quite easy if you can live with some small
restrictions. If you look at the conduits thread I think I posted my
toy form-walker which does this. Basically, you need to write a
function which walks over the form before you evaluate it and checks
for no naughty symbols. You probably also want to catch calls to
intern and things like assignments to *package* (or just any use of
*package*)
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.
--tim
Erik Naggum
| 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)
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.
#:Erik
--
I agree with everything you say, but I would
attack to death your right to say it.
-- Tom Stoppard
Tunc Simsek
>
> Tunc Simsek wrote:
>
> > regards,
> >
> > 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)
>
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.
> garbage-collected systems. Think of what would happen, if you would "delete"
> an object that is referenced by some other object or needed in a
> calculatoin somewhere! If you have problem with generating a huge amount of
> short-living objects, a Common Lisp with a generational GC could help.
the problem is not of memory; it is of 'desire' to be able to do this.
Thanks,
tunc
Tunc Simsek
>
> > regards,
> >
> > 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)
>
> to do something like that, you have to program it
> yourself. Usually an object is unnamed and does not
> know about references to itself.
>
> 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.
>
I'm familiar (somewhat) with finalization. I believe that
you still cannot force the collection of a particular object
(that is, you cannot claim that object as garbage)
> > 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.
>
> You would need to change the reader.
yes, I was hoping that there is a simple trick in the
reader table with which something could be done.
>
> Note:
>
> (funcall (symbol-function (find-symbol "MY-SECRET-FUNCTION"
> "MY-SECRET-PACKAGE"))
> 42)
>
certainly eval and friends are in my list of bad functions :)
Thanks,
Tunc
Jochen Schmidt
If you do so, the places that reference that object realize, when it
vanished. The downside is that you have to do all accesses to your object
indirectly.
Regards,
Jochen Schmidt
Tunc Simsek wrote:
> regards,
>
> 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.
>
> Thanks,
> Tunc
--
Francis Leboutte
>* Tunc Simsek wrote:
>> regards,
>> 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)
>
>I think you'd do this the same way you'd do it in, say C++: you need
>to do something like keep a list of all objects that refer to the
>object in question, and at delete time walk down it and make all the
>refs be to nil (you need to keep a method' to make the reference be
>nil too). Alternative approaches would be to make all references be
>indirect through (say) a hash table, and then replace the object in
>the hashtable by nil, or finding a solution which doesn't involve
>doing this. (Note that in, say C++, deleting an object doesn't make
>people who refer to it refer to nil (or the C++ equivalent), it leaves
>them referring to completely random bits of memory which used to hold
>the object, unless you implement a scheme like the above).
The ultimate alternative approach :-) ... persistence and use of an ODBMS
like PLOB and Allegrostore
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)))
--
Francis Leboutte
www.algo.be +32-(0)4.388.39.19
Jochen Schmidt
> ------
>
> 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.
"delete", "free" and co. is not "needed", because CommonLisp uses a
Garbage-Collector. (As you surely know)
> 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.
It's the Way Garbage-Collection works - in GC-Systems you will ever only see
a "new" but never a "delete". The Reason is, that if you mark an object as
deleted, it possibly is used somewhere else in computation. If you have bad
luck, then the Garbage Collector jumps over to the Free-Mem-List ....boom!
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"
>
> the problem is not of memory; it is of 'desire' to be able to do this.
see above
Regards
Jochen
Pierre R. Mai
> 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)
As Erik has already suggested, use change-class. Indeed it seems to
me that you really want to use change-class anyway, since it fits the
semantics of your problem nicely:
(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))
> 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.
Hasn't this been handled in prior discussions on safe CL subsets? Take
a look at deja.com...
Regs, Pierre.
--
Pierre R. Mai <pm...@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
Christopher Browne
the artist formerly known as Tunc Simsek said:
>Jochen Schmidt wrote:
>>
>> Tunc Simsek wrote:
>>
>> > regards,
>> >
>> > 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)
>>
> ------
>
>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.
>
>objects is not defined in ANSI CL but extensions in particular
>implementations should be possible.
Why do you think that this is forcibly _needed_?
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.
>> garbage-collected systems. Think of what would happen, if you
>> would "delete" an object that is referenced by some other object
>> or needed in a calculatoin somewhere! If you have problem with
>> generating a huge amount of short-living objects, a Common Lisp with
>> a generational GC could help.
>
>the problem is not of memory; it is of 'desire' to be able to do this.
There's no problem; you need only throw away the references, and
the automobile object will indeed get deleted. It may not happen
immediately, but that is of little importance. The only reason for it
to be of importance would be if you were short on memory, in which
case it's pretty likely that the object would indeed get reaped
quite soon indeed.
--
cbbr...@hex.net - <http://www.ntlug.org/~cbbrowne/linux.html>
Do not meddle in the affairs of dragons, for you are crunchy and taste
good with ketchup.
Tim Bradshaw
> the problem is not of memory; it is of 'desire' to be able to do this.
>
But why do you *desire* to be able to do it? it seems to me that
there are really two useful things you might want to be able to do:
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.
--tim
Tim Bradshaw
> 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.
>
Before someone picks me up, not `delete', obviously. Perhaps
`delete-object' or something. Sorry!
--tim
Erik Naggum
| Why do you think that this is forcibly _needed_?
|
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?
Christopher J. Vogt
>
> Jochen Schmidt wrote:
> >
> > Tunc Simsek wrote:
> >
> > > regards,
> > >
> > > 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)
> >
> > Something like a "delete" or "free" is neither needed nor possible in
> ------
>
> 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.
While you can't (or at least can't easily) destroy a CLOS object from the
Lisp environment, you certainly can do it from your simulation environment.
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.
> > garbage-collected systems. Think of what would happen, if you would "delete"
> > an object that is referenced by some other object or needed in a
> > calculatoin somewhere! If you have problem with generating a huge amount of
> > short-living objects, a Common Lisp with a generational GC could help.
>
> the problem is not of memory; it is of 'desire' to be able to do this.
Lisp is designed to provide a rather robust environment. In order to provide a
robust environment it can't allow you to do everything you want. 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. Many popular languages
work this way. Lisp does not.
Marco Antoniotti
Of course if
(make-hash-table :weak-p t)
were in the Standard..... :{
Cheers
--
Marco Antoniotti =============================================================
NYU Bioinformatics Group tel. +1 - 212 - 998 3488
719 Broadway 12th Floor fax +1 - 212 - 995 4122
New York, NY 10003, USA http://galt.mrl.nyu.edu/valis
Like DNA, such a language [Lisp] does not go out of style.
Paul Graham, ANSI Common Lisp
Barry Margolin
>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)
Because until you do this, the garbage collector won't treat is as garbage,
so it will continue to use up memory. If you have lots of such objects and
they're large (or refer to lots of other objects), the memory impact can be
significant, which could increase the resident set, which will reduce
performance.
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.
--
Barry Margolin, bar...@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Tim Bradshaw
[ In response to my comment on nullifying references]
>
> Because until you do this, the garbage collector won't treat is as garbage,
> so it will continue to use up memory. If you have lots of such objects and
> they're large (or refer to lots of other objects), the memory impact can be
> significant, which could increase the resident set, which will reduce
> performance.
>
I was being incoherent, sorry. I was trying to distinguish between
`do something which will cause the GC to (later, perhaps effectively
never if the object is tenured...) collect the object', and `do
something which causes it to be `collected' *now*', which I think
seemed to be what the original poster was after. Of course I could be
wrong about that: partly I was trying to elicit a response about what
they do want...
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?
--tim
Kenny Tilton
> 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.
Well how does "this component" find out about spewed vehicles? My point is, it
does not learn of them miraculously <g>, so why should it forget them
miraculously?
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.
kenny
Erik Naggum
| Lisp is designed to provide a rather robust environment. In order
| to provide a robust environment it can't allow you to do everything
| you want.
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?
Kenny Tilton
> * "Christopher J. Vogt" <vo...@computer.org>
> | Lisp is designed to provide a rather robust environment. In order
> | to provide a robust environment it can't allow you to do everything
> | you want.
>
> Really? It can't _allow_ that, huh? What happens if I try?
Then the security offered by not trying is lost and nothing then stands
between you and the hot blast of evil but your own two frontal lobes,
sufficient perhaps for you, but why recomend such recklessness to one
lacking your admitted skill? Sh*t man, Einstein could get away with
GOTOs...does that make them one scintilla less damnable? (Hint: no.)
> 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"?
Somewhere in the middle of that paragraph
> | Many popular languages work this way. Lisp does not.
>
> This is nonsense. "Lisp" has no such restrictions,
Oh man, what a nit-picking quibble. All the dude is talking about is good
common practice, why strike this holier-than-thou
oh-yeah?-lisp-can-do-anything pose? 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...
> 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
wow, we were trying to decide how component Y could discover component X
had lost interest in certain instances, but now we are on a Holy Crusade
to save people from "something else"...yeah, god forbid we should get any
work done, or actually help the original correspondent with their actual
question...let's take every question on this NG and in as few exhanges as
possible get the adrenalin level up to "holy war" so we can keep this NG
safe for our children...
> Shed your misconceptions and try to think about what Lisp for really
> low-level stuff would be like.
Hey, lesson #1, never tell other people what they should do.
> 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?
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?
kenny
Boris Schaefer
| Then the security offered by not trying is lost and nothing then
| stands between you and the hot blast of evil but your own two
| frontal lobes, sufficient perhaps for you, but why recomend such
| recklessness to one lacking your admitted skill? Sh*t man, Einstein
| could get away with GOTOs...does that make them one scintilla less
| damnable? (Hint: no.)
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/>
Don't interfere with the stranger's style.
Erik Naggum
| Then the security offered by not trying is lost and nothing then
| stands between you and the hot blast of evil but your own two
| frontal lobes, sufficient perhaps for you, but why recomend such
| recklessness to one lacking your admitted skill?
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.
Kenny Tilton
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.
> 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.
OK, but the gentleman had indeed given a solution, in some detail. And
you are right, I stand corrected, Mr. Naggum had indeed offered a
solution, I take that bit back. (Neither of my freaking NG servers show
it, but I saw it referenced in another message.)
kenny