Hi,
I want to extend STRING class to be able to store all SUBSEQ
combinations of the related string. For this purpose, I created a
class like below.
(defclass string-with-cached-subseqs (string)
((subseqs
:initarg :subseqs
:accessor :subseqs-of
:type '(simple-array string (* *))
:documentation "2D array of STRING's SUBSEQS where array
subscripts are respectively START and END of the related SUBSEQ
output.")))
For me, suprisingly SBCL complained that
The class #<BUILT-IN-CLASS STRING> was specified as
a
super-class of the class
#<STANDARD-CLASS STRING-WITH-CACHED-SUBSEQS>, but
the
meta-classes #<STANDARD-CLASS BUILT-IN-CLASS>
and
#<STANDARD-CLASS STANDARD-CLASS> are incompatible. Define
a
method for SB-MOP:VALIDATE-SUPERCLASS to avoid this error.
Error message explicitly explains the way to fix the problem. But if
I'd use SB-MOP:VALIDATE-SUPERCLASS it'll break to compatibility of my
code for other lisp implementations. Here are my questions:
1. Is there any MOP package I can use to implement VALIDATE-SUPERCLASS
portably.
2. Am I on the wrong way by trying to extend the STRING class. I
thought it would make things easier by being able to benefit from
STRING specialized methods. How should I impelement what I want to
achieve?
Regards.
In article
<····································@c65g2000hsa.googlegroups.com>,
Volkan YAZICI <·············@gmail.com> wrote:
> Hi,
>
> I want to extend STRING class to be able to store all SUBSEQ
> combinations of the related string. For this purpose, I created a
> class like below.
>
> (defclass string-with-cached-subseqs (string)
> ((subseqs
> :initarg :subseqs
> :accessor :subseqs-of
> :type '(simple-array string (* *))
> :documentation "2D array of STRING's SUBSEQS where array
> subscripts are respectively START and END of the related SUBSEQ
> output.")))
This will not work. You can't extend STRING that way.
CL-USER 11 > (find-class 'string)
#<BUILT-IN-CLASS STRING 40F0334C83>
STRING is a built-in-class and not a CLOS standard class.
You can't define subclasses of string. The class hierarchy
for built-in classes is fixed and not extensible for the user.
Sometimes you wish to be able to do that. But ANSI CL
does not have that.
Compare that with the Dylan idea of 'Collections':
http://lispm.dyndns.org/documentation/prefix-dylan/book.annotated/ch12.html
...
> The class #<BUILT-IN-CLASS STRING> was specified as
> a
> super-class of the class
> #<STANDARD-CLASS STRING-WITH-CACHED-SUBSEQS>, but
> the
> meta-classes #<STANDARD-CLASS BUILT-IN-CLASS>
> and
> #<STANDARD-CLASS STANDARD-CLASS> are incompatible. Define
> a
> method for SB-MOP:VALIDATE-SUPERCLASS to avoid this error.
>
> Error message explicitly explains the way to fix the problem. But if
> I'd use SB-MOP:VALIDATE-SUPERCLASS it'll break to compatibility of my
> code for other lisp implementations. Here are my questions:
>
> 1. Is there any MOP package I can use to implement VALIDATE-SUPERCLASS
> portably.
>
> 2. Am I on the wrong way by trying to extend the STRING class. I
> thought it would make things easier by being able to benefit from
> STRING specialized methods. How should I impelement what I want to
> achieve?
You can write STRING specialized methods:
(defmethod foo ((s string))
(do-something s))
But you can't redefine existing functions like LENGTH
and you can't subclass built-in classes.
LENGTH is a normal function and you are not allowed
(in portable code) to replace it with a generic function.
The typical way to define for example your own version
of length, is to do it in a package:
; package MY-EXTENDED-COMMON-LISP. MECL. Has its own symbol LENGTH
; exported...
(defmethod mecl:length ((s string)
(cl:length s))
and so on. But that's for experts and quite a bit work
to get things right.
Possibly there is already something in the direction - haven't looked
for that yet.
>
>
> Regards.
--
http://lispm.dyndns.org/
Rainer Joswig <······@lisp.de> writes:
> STRING is a built-in-class and not a CLOS standard class.
> You can't define subclasses of string. The class hierarchy
> for built-in classes is fixed and not extensible for the user.
>
> Sometimes you wish to be able to do that. But ANSI CL
> does not have that.
>
> Compare that with the Dylan idea of 'Collections':
>
> http://lispm.dyndns.org/documentation/prefix-dylan/book.annotated/ch12.html
While not ANSI CL, SBCL supports extensible sequences.
The OP should take a look at
http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf
-T.
In article <··············@freebits.de>,
"Tobias C. Rittweiler" <···@freebits.de.invalid> wrote:
> Rainer Joswig <······@lisp.de> writes:
>
> > STRING is a built-in-class and not a CLOS standard class.
> > You can't define subclasses of string. The class hierarchy
> > for built-in classes is fixed and not extensible for the user.
> >
> > Sometimes you wish to be able to do that. But ANSI CL
> > does not have that.
> >
> > Compare that with the Dylan idea of 'Collections':
> >
> > http://lispm.dyndns.org/documentation/prefix-dylan/book.annotated/ch12.html
>
> While not ANSI CL, SBCL supports extensible sequences.
>
> The OP should take a look at
>
> http://www.doc.gold.ac.uk/~mas01cr/papers/ilc2007/sequences-20070301.pdf
>
> -T.
Right, that's an very good paper. It describes how to
extend and subclass sequences. That's certainly very useful
(currently I have a use for that, too).
But it still does not allow one to subclass strings and
extend the various operations on strings
(MAKE-STRING, STRING-TRIM, STRING-UPCASE, STRINGP, STRING=, CHAR, ...).
Also one would want the other operations that use strings
would accept (or create strings using) the new string class.
Much of the base language of ANSI CL is not that extensible.
Still, if there would be ever a revision of ANSI CL, the
above mentioned extensible sequences would be a useful contribution.
--
http://lispm.dyndns.org/
On 2008-08-21, Rainer Joswig <······@lisp.de> wrote:
> In article
><····································@c65g2000hsa.googlegroups.com>,
> Volkan YAZICI <·············@gmail.com> wrote:
>
>> Hi,
>>
>> I want to extend STRING class to be able to store all SUBSEQ
>> combinations of the related string. For this purpose, I created a
>> class like below.
>>
>> (defclass string-with-cached-subseqs (string)
>> ((subseqs
>> :initarg :subseqs
>> :accessor :subseqs-of
>> :type '(simple-array string (* *))
>> :documentation "2D array of STRING's SUBSEQS where array
>> subscripts are respectively START and END of the related SUBSEQ
>> output.")))
>
> This will not work. You can't extend STRING that way.
Moreover, there are these points to consider:
- In Lisp, objects don't have to be derived from a common base class
in order to be useable with the same generic functions.
You can have two string-like types which work with the
same generic functions, but are not related in the type lattice.
Given some generic functions that work with the standard STRING
class, you can specialize them to work with your custom string class
without inheritance.
- Common Lisp, although it provides a string class, doesn't provide
any generic functions specific to strings. Any generic functions that work
with strings (of any kind) will either come from you or some third-party
library.
Volkan YAZICI <·············@gmail.com> writes:
> Hi,
>
> I want to extend STRING class to be able to store all SUBSEQ
> combinations of the related string. For this purpose, I created a
> class like below.
>
> (defclass string-with-cached-subseqs (string)
> ((subseqs
> :initarg :subseqs
> :accessor :subseqs-of
> :type '(simple-array string (* *))
> :documentation "2D array of STRING's SUBSEQS where array
> subscripts are respectively START and END of the related SUBSEQ
> output.")))
>
> For me, suprisingly SBCL complained that
>
> The class #<BUILT-IN-CLASS STRING> was specified as
Yes.
Rainer explained why.
> 1. Is there any MOP package I can use to implement VALIDATE-SUPERCLASS
> portably.
CLOSER-MOP Find it on cliki.net
> 2. Am I on the wrong way by trying to extend the STRING class. I
> thought it would make things easier by being able to benefit from
> STRING specialized methods. How should I impelement what I want to
> achieve?
So you want to keep all subseq combinations related to a string?
There's no need to keep them encapsulated with the lisp string itself.
Of course, you can still abstract away that encapsulation.
So you want:
(subseqs-of string) --> 2d-array-of-substrings
To implement that portably, there will be the difficulty that the
string won't be garbage collected as long as we keep a reference to
it, so we'll need a method to "free" it.
(free string)
An alternative would be to use an implementation specific weak
something of some kind (weak hash tables, weak pointers, etc).
(or a compatibility layer such as
http://darcs.informatimago.com/lisp/clext/closer-weak.lisp )
But let's stay 100% CL portable.
(defvar *subseqs-of-string-map* (make-hash-table))
;; Note since objects have EQL identity, we use an EQL hash table for
;; our strings. That's what you're asking for...
(defmethod subseqs-of ((self string))
(or (gethash self *subseqs-of-string-map*)
(setf (gethash self *subseqs-of-string-map*)
(compute-subseqs-of-string self))))
(defmethod free ((self string))
(remhash self *subseqs-of-string-map*)
self)
(defmethod compute-subseqs-of-string ((self string))
(loop
:with result = (make-array (list (1+ (length string)) (1+ (length string))))
:for start :from 0 :to (length string)
:do (loop :for end :from 0 :to (length string)
:do (setf (aref result start end)
(COM.INFORMATIMAGO.COMMON-LISP.UTILITY:NSUBSEQ string start end)))
:finally (return result)))
Notice the use of NSUBSEQ which builds displaced arrays to avoid
copying the original characters N^2 times...
This is still quite a waste, do you really need to keep all these
substrings? NSUBSEQ is rather efficient, and if you need to scan over
the subseqs often, you could even use only one displaced array that
you would update, having thus only one pointer and one length to
update from one substring to the other.
NSUBSEQ can be found in:
http://darcs.informatimago.com/lisp/common-lisp/utility.lisp
--
__Pascal Bourguignon__
On Aug 21, 3:00 pm, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> So you want to keep all subseq combinations related to a string?
> There's no need to keep them encapsulated with the lisp string itself.
> Of course, you can still abstract away that encapsulation.
> So you want:
>
> (subseqs-of string) --> 2d-array-of-substrings
That is exactly what I want to achieve.
> To implement that portably, there will be the difficulty that the
> string won't be garbage collected as long as we keep a reference to
> it, so we'll need a method to "free" it.
>
> (free string)
>
> An alternative would be to use an implementation specific weak
> something of some kind (weak hash tables, weak pointers, etc).
> (or a compatibility layer such as
> http://darcs.informatimago.com/lisp/clext/closer-weak.lisp)
>
> But let's stay 100% CL portable.
Please.
> (defvar *subseqs-of-string-map* (make-hash-table))
> ;; Note since objects have EQL identity, we use an EQL hash table for
> ;; our strings. That's what you're asking for...
>
> (defmethod subseqs-of ((self string))
> (or (gethash self *subseqs-of-string-map*)
> (setf (gethash self *subseqs-of-string-map*)
> (compute-subseqs-of-string self))))
>
> (defmethod free ((self string))
> (remhash self *subseqs-of-string-map*)
> self)
Hrm... I see. That's fine too. But AFAIK, there is no FREE in ANSI CL.
Am I mistaken? How is FREE supposed to work?
> Notice the use of NSUBSEQ which builds displaced arrays to avoid
> copying the original characters N^2 times...
Yep, that is something I had in mind to use.
> This is still quite a waste, do you really need to keep all these
> substrings?
I'll use pre-computed SUBSEQ values for fast dictionary look-ups.
Regards.
Volkan YAZICI <·············@gmail.com> wrote:
+---------------
| ····@informatimago.com (Pascal J. Bourguignon) wrote:
| > (defmethod free ((self string))
| > (remhash self *subseqs-of-string-map*)
| > self)
|
| Hrm... I see. That's fine too. But AFAIK, there is no FREE in ANSI CL.
| Am I mistaken? How is FREE supposed to work?
+---------------
All it does it remove the argument from the hash table, thus
removing the reference to the argument *by* the hash table that
would prevent it from being GC'd. [There may still be *other*
references to the object in your code; it's up to you to remove
or overwrite those.]
You are correct that there is no built-in FREE in CL. But
all you have to do in CL to "free" an object is remove *all*
references to the object [turning it into "garbage"], and
the GC will (eventually) come along and discover the lack of
any such references and collect the space used by the object.
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
····@rpw3.org (Rob Warnock) wrote on Thu, 21 Aug 2008:
> You are correct that there is no built-in FREE in CL. But all you have to
> do in CL to "free" an object is remove *all* references to the object
> [turning it into "garbage"], and the GC will (eventually) come along and
> discover the lack of any such references and collect the space used by the
> object.
You know, everybody describes it that way. But GCs really work by finding
still-used memory (and copying it elsewhere), not by finding garbage. They
never actually "discover the lack of references". There's not an explicit
step in the algorithm, where it suddenly concludes: "Ah ha! There are no
longer any references to this little block of memory! I'll collect it."
Obviously you know this already, but I always found it ironic that the
standard one-line explanation (and even the name!) of "garbage collection"
isn't really correct.
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
Fun Facts for the Psychotic:
The cuddly "Koala bear" of Australia is actually not a "bear" at all...
...it is a telepathic cyborg that reports your thoughts to "The Council"!
-- Ruben Bolling, "Tom The Dancing Bug", #746
On Thu, 21 Aug 2008 12:27:40 -0700, Don Geddis wrote:
> ····@rpw3.org (Rob Warnock) wrote on Thu, 21 Aug 2008:
>> You are correct that there is no built-in FREE in CL. But all you have
>> to do in CL to "free" an object is remove *all* references to the
>> object [turning it into "garbage"], and the GC will (eventually) come
>> along and discover the lack of any such references and collect the
>> space used by the object.
>
> You know, everybody describes it that way. But GCs really work by
> finding still-used memory (and copying it elsewhere), not by finding
> garbage. They never actually "discover the lack of references".
> There's not an explicit step in the algorithm, where it suddenly
> concludes: "Ah ha! There are no longer any references to this little
> block of memory! I'll collect it."
Mark-and-sweep really can work in the way Rob Warnock described.
One example is the GC in Franz Lisp
<http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/others/
franzlsp/op38_93b/franzlsp.tgz>
Robert Swindells
In article <·····················@news.demon.co.uk>,
Robert Swindells <···@fdy2.demon.co.uk> wrote:
> On Thu, 21 Aug 2008 12:27:40 -0700, Don Geddis wrote:
>
> > ····@rpw3.org (Rob Warnock) wrote on Thu, 21 Aug 2008:
> >> You are correct that there is no built-in FREE in CL. But all you have
> >> to do in CL to "free" an object is remove *all* references to the
> >> object [turning it into "garbage"], and the GC will (eventually) come
> >> along and discover the lack of any such references and collect the
> >> space used by the object.
> >
> > You know, everybody describes it that way. But GCs really work by
> > finding still-used memory (and copying it elsewhere), not by finding
> > garbage. They never actually "discover the lack of references".
> > There's not an explicit step in the algorithm, where it suddenly
> > concludes: "Ah ha! There are no longer any references to this little
> > block of memory! I'll collect it."
>
> Mark-and-sweep really can work in the way Rob Warnock described.
And reference counting really does suddenly conclude that there are no
references to the block of memory, when its refcount drops to 0.
--
Barry Margolin, ······@alum.mit.edu
Arlington, MA
*** PLEASE post questions in newsgroups, not directly to me ***
*** PLEASE don't copy me on replies, I'll read them in the group ***
On Thu, 21 Aug 2008 12:27:40 -0700, Don Geddis wrote:
> ····@rpw3.org (Rob Warnock) wrote on Thu, 21 Aug 2008:
>> You are correct that there is no built-in FREE in CL. But all you have
>> to do in CL to "free" an object is remove *all* references to the
>> object [turning it into "garbage"], and the GC will (eventually) come
>> along and discover the lack of any such references and collect the
>> space used by the object.
>
> You know, everybody describes it that way. But GCs really work by
> finding still-used memory (and copying it elsewhere), not by finding
> garbage. They never actually "discover the lack of references".
> There's not an explicit step in the algorithm, where it suddenly
> concludes: "Ah ha! There are no longer any references to this little
> block of memory! I'll collect it."
Mark-and-sweep really can work in the way Rob Warnock described.
One example is the GC in Franz Lisp
<http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/lang/others/
franzlsp/op38_93b/franzlsp.tgz>
Robert Swindells
On Thu, 21 Aug 2008 12:27:40 -0700, Don Geddis <···@geddis.org> wrote:
>····@rpw3.org (Rob Warnock) wrote on Thu, 21 Aug 2008:
>> You are correct that there is no built-in FREE in CL. But all you have to
>> do in CL to "free" an object is remove *all* references to the object
>> [turning it into "garbage"], and the GC will (eventually) come along and
>> discover the lack of any such references and collect the space used by the
>> object.
>
>You know, everybody describes it that way. But GCs really work by finding
>still-used memory (and copying it elsewhere), not by finding garbage. They
>never actually "discover the lack of references". There's not an explicit
>step in the algorithm, where it suddenly concludes: "Ah ha! There are no
>longer any references to this little block of memory! I'll collect it."
Not exactly. Any non-copying collector has the potential to work by
identifying garbage - all reference counters do and I know of at least
one concurrent mark-sweep design that does also. But for almost all
purposes it's more efficient to identify live objects instead.
Non-copying collectors also must touch the garbage space to recycle it
so it obviously has to be identified.
>Obviously you know this already, but I always found it ironic that the
>standard one-line explanation (and even the name!) of "garbage collection"
>isn't really correct.
>
> -- Don
Yeah, it's really a combination of census taker and undertaker.
George
P� Fri, 22 Aug 2008 21:18:47 +0200, skrev George Neuner
<········@comcast.net>:
>
> Not exactly. Any non-copying collector has the potential to work by
> identifying garbage - all reference counters do and I know of at least
> one concurrent mark-sweep design that does also. But for almost all
> purposes it's more efficient to identify live objects instead.
>
It it common to collect garbage rather than copy 'live' data in C/C++
garbage collectors.
Lisp keeps a array of locations on the heap where the data is stored. The
location the variable stores is just a index in this array.
In C on the other hand you store the address on the heap directly so
moving the memory here would be disastrous.
Hence you need to keep things where they were.
The Boehm-Demers-Weiser conservative garbage collector is a example of
this.
--------------
John Thingstad
"John Thingstad" <·······@online.no> wrote on Fri, 22 Aug 2008:
> > Fri, 22 Aug 2008 21:18:47 +0200, skrev George Neuner <········@comcast.net>:
>> Not exactly. Any non-copying collector has the potential to work by
>> identifying garbage - all reference counters do and I know of at least
>> one concurrent mark-sweep design that does also. But for almost all
>> purposes it's more efficient to identify live objects instead.
>
> It it common to collect garbage rather than copy 'live' data in C/C++
> garbage collectors. Lisp keeps a array of locations on the heap where the
> data is stored. The location the variable stores is just a index in this
> array. In C on the other hand you store the address on the heap directly
> so moving the memory here would be disastrous. Hence you need to keep
> things where they were. The Boehm-Demers-Weiser conservative garbage
> collector is a example of this.
Thanks for the corrections, everybody. Sorry for my misinformation.
I confused the typical way that modern CL GC works, with the obvious
way that every GC ought to work. Clearly, the standard description
indeed does apply to some GCs (especially older ones or non-CL ones).
-- Don
_______________________________________________________________________________
Don Geddis http://don.geddis.org/ ···@geddis.org
I wish I would have a real tragic love affair and get so bummed out that I'd
just quit my job and become a bum for a few years, because I was thinking about
doing that anyway. -- Deep Thoughts, by Jack Handey
On Aug 22, 9:44 pm, "John Thingstad" <·······@online.no> wrote:
> På Fri, 22 Aug 2008 21:18:47 +0200, skrev George Neuner
> <········@comcast.net>:
>
>
>
> > Not exactly. Any non-copying collector has the potential to work by
> > identifying garbage - all reference counters do and I know of at least
> > one concurrent mark-sweep design that does also. But for almost all
> > purposes it's more efficient to identify live objects instead.
>
> It it common to collect garbage rather than copy 'live' data in C/C++
> garbage collectors.
> Lisp keeps a array of locations on the heap where the data is stored. The
> location the variable stores is just a index in this array.
What? Uh, no.
> In C on the other hand you store the address on the heap directly so
> moving the memory here would be disastrous.
No, most/all Lisp implementations store pointers on the heap.
> Hence you need to keep things where they were.
> The Boehm-Demers-Weiser conservative garbage collector is a example of
> this.
The conservativism is because you cannot unambiguously tell a pointer
from an integer from a ... in C. In implementing languages intended to
have GCs, if you know how to find the root set of pointers (stack,
registers), you can find all live objects by following those. When you
find a pointer to some place on the stack, you can tell by the tag
bits where the pointers are.
And you can implement moving collectors for C++, if you require the
user to always use smart pointers.
On Sat, 23 Aug 2008 03:46:37 -0700 (PDT), "Thomas F. Burdick"
<········@gmail.com> wrote:
>On Aug 22, 9:44�pm, "John Thingstad" <·······@online.no> wrote:
>> P� Fri, 22 Aug 2008 21:18:47 +0200, skrev George Neuner �
>> <········@comcast.net>:
>>
>>
>>
>> > Not exactly. �Any non-copying collector has the potential to work by
>> > identifying garbage - all reference counters do and I know of at least
>> > one concurrent mark-sweep design that does also. �But for almost all
>> > purposes it's more efficient to identify live objects instead.
>>
>> It it common to collect garbage rather than copy 'live' data in C/C++ �
>> garbage collectors.
>> Lisp keeps a array of locations on the heap where the data is stored. The �
>> location the variable stores is just a index in this array.
>
>What? Uh, no.
>
>> In C on the other hand you store the address on the heap directly so �
>> moving the memory here would be disastrous.
>
>No, most/all Lisp implementations store pointers on the heap.
>
>> Hence you need to keep things where they were.
>> The Boehm-Demers-Weiser conservative garbage collector is a example of �
>> this.
>
>The conservativism is because you cannot unambiguously tell a pointer
>from an integer from a ... in C. In implementing languages intended to
>have GCs, if you know how to find the root set of pointers (stack,
>registers), you can find all live objects by following those. When you
>find a pointer to some place on the stack, you can tell by the tag
>bits where the pointers are.
>
>And you can implement moving collectors for C++, if you require the
>user to always use smart pointers.
Or if you arrange that the compiler always maintains the base pointer
to the allocated block. One of the main challenges for GC in C/C++ is
that there is no requirement for base pointers to be kept intact.
Optimized code can easily result in the only pointer to an allocation
being internal or past the end of the block.
George
P� Fri, 22 Aug 2008 21:44:49 +0200, skrev John Thingstad
<·······@online.no>:
> P� Fri, 22 Aug 2008 21:18:47 +0200, skrev George Neuner
> <········@comcast.net>:
>
>>
>> Not exactly. Any non-copying collector has the potential to work by
>> identifying garbage - all reference counters do and I know of at least
>> one concurrent mark-sweep design that does also. But for almost all
>> purposes it's more efficient to identify live objects instead.
>>
>
> It it common to collect garbage rather than copy 'live' data in C/C++
> garbage collectors.
> Lisp keeps a array of locations on the heap where the data is stored.
> The location the variable stores is just a index in this array.
> In C on the other hand you store the address on the heap directly so
> moving the memory here would be disastrous.
> Hence you need to keep things where they were.
> The Boehm-Demers-Weiser conservative garbage collector is a example of
> this.
Looking this over I think I should have added that that CL compilers that
compile to C mainly ECL and GCL use the above mentioned collector.
Thus you might encounter this in CL as well.
--------------
John Thingstad
Don Geddis schrieb:
> ····@rpw3.org (Rob Warnock) wrote on Thu, 21 Aug 2008:
>> You are correct that there is no built-in FREE in CL. But all you have to
>> do in CL to "free" an object is remove *all* references to the object
>> [turning it into "garbage"], and the GC will (eventually) come along and
>> discover the lack of any such references and collect the space used by the
>> object.
>
> You know, everybody describes it that way. But GCs really work by finding
> still-used memory (and copying it elsewhere), not by finding garbage. They
> never actually "discover the lack of references". There's not an explicit
> step in the algorithm, where it suddenly concludes: "Ah ha! There are no
> longer any references to this little block of memory! I'll collect it."
>
> Obviously you know this already, but I always found it ironic that the
> standard one-line explanation (and even the name!) of "garbage collection"
> isn't really correct.
Also have a look at page 16 of the comic of Googles new web browser:
http://www.google.com/googlebooks/chrome/
Andr�
--