Thanks for the vote of confidence, bu I should point
out that I am the brainpower in this case, along with a stack of
books and papers by people rather more clever than I am. If it was
easy or inexpensive to do this, I wouldn't be asking the
Ah, then your solution is indeed somewhat different. I would suggest
instead a garbage collection API,
While there will be a GC API, unfortunately it's not the solution in
this case. Reference counting can't be added in after the fact, since it
involves a lot of code, scattered through all the core and extension source, hat we wouldn't otherwise be writing. That's
one of the advantages to tracing collectors--you don't have to worry
about GC code in your mainline code.
I think your determination that refcounting is the only solution for a
language with references is premature.
Unfortunately not. For true timely DESTROY calling, it's the only
option. (Though whether destruction can ever be truly deterministic
in the presence of threads, closures, and continuations is up in the
Choosing timely destruction in the face of references requires refcounting. (timely, here,
meaning "as soon as the last reference to an object goes away")
There's no way to do static analysis of a program such that you can
determine at compile time when a variable is no longer used, since
taking a reference allows a variable to escape its scope. Throw in
some of the heavy introspection capabilities that are on the way and
you're completely out of luck, since library code you may not know
about can peek at and take references to your lexicals.
Since we can't do static analysis, that requires a runtime
solution. And for that it's either tracing every time a variable dies
(which is really pricey), or reference counting.
So, in summary, it is my determination (still :) that the
option needs to be available for deterministic GC.
But the question is still why
? For what purpose? What will
break, besides personal comfort, without at least the illusion of
timely destruction? Abigail's given a few examples, most of which
can be dealt with in other ways. How many classes have you written
that both have a DESTROY and
would behave oddly if the
timing of those DESTROY calls weren't apparently set in stone? And if you have them, at what granularity is DESTROY calling acceptable?