Yes, I intentionally didn't go into other issues of reference counting, they being outside the point of my node.

Only recently did I look at how Perl 5 implemented reference counting enough to realize how horribly it was done. I'm not at all surprised that there are still bugs in that implementation. Perl 5 reference counting mostly requires matching each creation and destruction of references by hand. It is a huge manual effort that is very error prone.

Of course, it isn't easy to design something in plain C that does a fantastic job of enforcing this type of thing. C++ offers great ways of dealing with this (destructors fire when you leave a scope, no matter how you left it; so doing such work in c'tors and d'tors ensures that your inc/decs are paired without having to match anything by-hand and even in the face of exceptions being thrown or early return).

But you can certainly put more effort into making the system better at encouraging and enforcing proper habits so you don't have to put so much effort into figuring out proper ref count handling by-hand every time you add or change just about any of Perl's source code and not producing a system that is so confusing that it is almost always a source of questions and bugs for new XS coders. But that ship has at least mostly already sailed for Perl 5.

It wouldn't be trivial to implement a good system for reference counting in plain C, but the failure of Perl 5's implementation to become error-free has more to do with that particular implementation not making the effort up front to make future errors unlikely.

And it has at least mostly already sailed for Parrot as well. And at this point I'm doubtful that Parrot will ever be successful enough for us to see how big of a mistake this particular choice was. I consider timely and well-order destructors one of the most important tools of C++ but the designers of Parrot had no understanding of this and little interest in trying to understand the arguments of those who did understand this importance. Basing a design decision on ignorance (that was how the decision was made; it was a fiat of "I don't understand why you guys think reference counting is a good idea, but it doesn't matter because I've already decided and I'm writing it and that's that") in the face of several knowledgeable people criticizing that decision isn't usually a formula for success.

I consider timely and well-order destructors one of the most important tools of C++ but the designers of Parrot had no understanding of this...

So either I have no say into the design of Parrot, or I don't understand timely and well-ordered destruction? (Ditto for the rest of @Larry.)

There are ways to manage timely destruction with a generational GC.

I said "had". I'm talking about a decision that was made long ago, when it was a one-man show. Are you trying to imply, by using "have", that you think there is a possibility for a design decision at this point of whether or not to use reference counting with Parrot? Or did you use "have" by mistake and you are now claiming that you helped Dan make the original decision and his "I" was a figure of speech?

If you are considering adding reference counting to Parrot at this point, after so much work has gone into it based on the decision to not do reference counting, then "it will be hard" is certainly a valid point. But that has more to do with trying to retro-fit something fundamental into an existing project.

That is why threading (the several different attempts at it) works so badly in Perl 5. Saying "Those all seem like implementation details" shows a real lack of understanding of the years-long struggle to retro-fit a fundamental design change (threading support) onto an existing project that (as BrowserUk described) was built in a way that is very unfriendly to threading.

Retro-fitting reference counting into a system that didn't take that into consideration as an early design choice is very likely doomed to failure. It is a fundamental feature that needs to be considered at quite a low level in the design (like threading needs to be).

There are ways to manage timely destruction with a generational GC.

Which shows your lack of understanding what "timely" means. I see no comment on "well-ordered". Certainly you can make destruction happen more quickly, and that makes it still useful for some classes of problems. But that isn't "timely", it is just "closer to timely" and still leaves problems for some important uses of destructors.

- tye