From: Dan Sugalski <[EMAIL PROTECTED]>
Date: Wed, 27 Apr 2005 15:43:32 -0400
At 5:40 PM +0200 4/27/05, Robin Redeker wrote:
>Just for the curious me: What was the design decision behind the GC
>solution? Was refcounting that bad? . . .
I'll answer this one, since I'm the one responsible for it.
Refcounting has three big issues:
1) It's expensive
2) It's error-prone
3) It misses circular garbage
. . .
The circular garbage thing's also an issue. Yes, there are
interesting hacks around it (python has one -- clever, but definitely
a hack) that essentially involves writing a separate mark&sweep
garbage collector.
The circular garbage issue is just as important as the others, IMHO.
Because Perl5 can't deal with circular garbage, many reasonable data
structures are awkward to implement, and Perl5 lexical closures are
close to useless because they leak memory.
. . .
Having been too deep into the guts of perl, and having written more
extensions in C than I care to admit to, I wanted refcounting *dead*.
Yay, Dan!
>You said, that most languages will have refcount semantics, just sounds
>funny for me to implement a GC then.
Actually most languages won't have refcount semantics. Perl 5's the
only one that really guarantees that sort of thing now, though I
think it's in there for perl 6. I doubt the python, ruby, Lisp, or
Tcl compilers will emit the cleanup-at-block-boundary sweep code.
--
Dan
For the record, Common Lisp does not even provide a finalization
mechanism; if you want something destroyed, you must do it explicitly,
while you still have a reference to the thing.
-- Bob Rogers
http://rgrjr.dyndns.org/
