My two strongest reactions are:

1. Please, please, please don't put in a "real" garbage collector. The two arguments seem to be improved performance and circular references. Yet, the research on garbage collection, right after it states that "mark and sweep" is more efficient, notes that users of "mark and sweep" can spend most of their time collecting garbage. I don't find circular references to be much of a problem (at least 98% of the complaints I've seen about lack of memory in Perl did not involve circular references). I already hear a lot more complaints about non-timely destructor activation than about circular references. The non-deterministic and very delayed activation of destructors plus the periodic load fluctuation of a "real" garbage collector will create orders of magnitide more complaints than the current overhead and circular reference "problems" have.
2. Many of the goals seem far from realistic. In particular, they start by stating that the core needs to be shrunk, requesting that lots of core stuff be moved out into separate modules (and mention a few simple items that can be move out) and then half of the remaining suggestions involve complex items that need to be handled by the core, some of which are currently handled rather nicely by modules.

It sounds like they are trying to please everyone, trying to make Perl perfect for all environments and all problems. This, of course, is impossible. This doesn't sound like Perl 6, this sounds like Sperl, some other language losely based on Perl.

I think they will be forced to mostly drop most of those suggestions (I hope they will realize this fairly early in the process). So my biggest worry is that Perl 6 will be saddled with garbage collection.

I sympathize (really!!) with your skepticism about mark-and-sweep GC for Perl.

However, as an internals hacker, I have to say that the final, absolute end of memory leaks is worth a high price. Just think of all the programmer time that can be spent on more useful pursuits than memory bookkeeping!

Besides, with the current RC implementation, you just aren't noticing all the CPU time drained away by all those inc's and dec's and jz's required to keep ref counts more or less in line with reality.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

And I like not noticing. Even if my code ran a little faster overall with mark-and-sweep GC, I'd rather have the consistancy of performance provided by RC. Now, if my code ran 10-times faster (or even 3-times faster) with GC, I'd put up with moderate burstiness. But Lisp programs spend 25% to 40% of their time doing GC. Are you really claiming that RC overhead is anywhere near that high?? Or is the nature of Perl that GC in it will be tons more efficient than it is in Lisp?

Are you implying that it will be easier to implement a correct version of GC than of RC? The research says that RC is easier to implement. Sure, we run into bugs in Perl's RC, especially when we extend a large, old code base in ways not originally envisioned. You propose that we won't run into any bugs in GC??

A question: Does mark-and-sweep even preserve destruction order? It doesn't sound like it but I've only read high-level descriptions

The document is also in the Perl6 mailing list archives at:

• http://tmtowtdi.perl.org/archive?1:mss:958:hecbogdfnlljeedjegpn
--
<http://www.dave.org.uk>

European Perl Conference - Sept 22/24 2000, ICA, London
<http://www.yapc.org/Europe/>