... there are some technical reasons, like parrot not properly supporting any threading...

To me, that argues for developer focus on making Parrot support parallelism and concurrency.

Only for backend specific code.

There's the problem, though. Either you write to a bland portability layer which supports the sanest bare-bones intersection of features across every platform to which you eventually want to port (and to have any hope of performance you have huge, platform-specific optimization layers which poke through the bland layer of pudding) or you spend more time porting between platforms and less time sharing code.

If you think you can attract enough black magic developers on these alternate platforms interested in discovering, creating, and maintaining the layers of jiggery-pokery necessary to make Perl 6 perform worth using, your best approach is the pudding layer.

Which wheel do you think are we re-inventing?

Any runtime for Perl 6 is going to end up looking a lot like Parrot.

("My goodness, chromatic! Wouldn't it be easier to port Parrot to these other VMs?" Why yes, yes it would.)

To me, that argues for developer focus on making Parrot support parallelism and concurrency.

I'd love that, but I don't see it happening.

Consider tt #757. It's an absolute show stopper for having threads in Rakudo, to the best of my knowledge. It has been open for 14 month. For about a year it has had a patch. Nobody applied it.

Why?

It's not the question of awareness - I've mentioned that patch at several parrotsketch meetings, and asked for review. No reaction.

My conclusion is that none of the core developers has the sufficient mixture of time, motivation, focus, skills and understanding of the code base and the issue to review the patch.

I haven't seen any indication that this is about to change. I also hate to go shouting on the mailing list and say "go focus on threads", because I know that other areas in parrot require just as much attention, probably more.

Any runtime for Perl 6 is going to end up looking a lot like Parrot.

Citation needed.

I can also assure you that any runtime for Perl 6 is going to end up looking very much different from the parrot we know today. It will need a garbage collector that doesn't switch off when we switch on threading. It will need a cross-platform JIT compiler. It will need to be installed into paths that contain spaces.

Parrot is moving in that direction, and so are other VMs. Lots of things have changed in the world of virtual machines since parrot has started to fly.

That said, we certainly don't plan to abandon parrot.

Perl 6 - links to (nearly) everything that is Perl 6.

My personal view is that if Perl6 (and Parrot) don't have built-in threading (or AnyEvent-style message passing) from day one, it will be immensively hard to retrofit all existing libraries to play well with that. So there really is a clock ticking against Perl6+Parrot on that topic, as having a solid IPC foundation that is not fork is really necessary for a language nowadays. It's a bit sad that nobody seems to share my view on the Perl6+Parrot teams, at least enough to push the issue.

I'm not convinced that threads sharing memory on the language level are really the way to go. I'm very fond of simply passing data as messages between all threads. I found that most race conditions do not arise at all when structuring my execution paths so they simply send and receive messages.

Why?

I'll review the patch today. This is the first I've seen it. With that said, we hope to merge Chandon's GSoC work in the near future.

Update: Good luck convincing the maintainers of almost any other VM to make changes to support a Perl 6 implementation or to speed up a Perl 6 implementation. You're not getting changes in the JVM. You might be able to convince Mono to make specific changes. I'm not sure the DLR is an appropriate target; I don't know if it has sufficient low-level support for necessary features.

Citation needed.

"Any runtime for Perl 6 is going to end up looking a lot like Parrot." (chromatic, multiple times over the past three years)

You need a virtual machine which can support polymorphic data types, a metamodel with typed undefs, multiple dispatch, continuations, laziness, lexicals, roles, partial application, captures, positional and named calling conventions with defaults, first-class functions, resumable exceptions, lexical encapsulation, and a mutable grammar engine. Did I mention interoperability with other languages such as Perl 5?

You can play the Turing trump and argue that you can implement all of that on an appropriately powerful box running a bootstrapped Forth interpreter as specified circa 1978 and you might be technically correct, but you're going to spend a lot of time writing trampolines to support the pudding layer. People who want to do so are welcome to do so. I'm happy to answer questions about how such a virtual machine might look.

I can also assure you that any runtime for Perl 6 is going to end up looking very much different from the parrot we know today. It will need a garbage collector that doesn't switch off when we switch on threading. It will need a cross-platform JIT compiler. It will need to be installed into paths that contain spaces.

I suppose the question is whether another runtime can create enough trampolines to prop up the as-yet-unported pudding layer sooner than we can fix those bugs in Parrot.

Lots of things have changed in the world of virtual machines since parrot has started to fly.

Indeed, which is the entire purpose of the Lorito project within Parrot.

Ok, whenever this word 'completion' crops up there is great deal of confusion as to what is complete. Complete in the sense Perl 5 is complete. Complete in terms of stability, spec compliance, production readiness, availability of libraries/documentation and usability. Complete not in the sense of halted development. Both Linux and Hurd are being actively developed, but Hurd is not complete in the same sense Linux is complete.

Everything else you mentioned is perfectly acceptable. Probably you can have a second look at the word 'Complete'.

Ok, whenever this word 'completion' crops up there is great deal of confusion as to what is complete.

That's correct. Which is why it's best to avoid it in a discussion about software.

Both Linux and Hurd are being actively developed, but Hurd is not complete in the same sense Linux is complete.

I see only gradual differences. And for a gradual difference it doesn't make sense to say "wait until ..."

Probably you can have a second look at the word 'Complete'.

I just took a second look. It seems half of the explanations there equate "complete" to "dead" if applied to software. So best avoid it.

Don't get me wrong, I don't love to pick on some minor language nits, but if you ask the question again without using words like "completed" or "finished", it will probably come up in a way that makes much more sense, and is much easier to answer in a meaningful way.

Perl 6 - links to (nearly) everything that is Perl 6.

Thanks that you noticed the difference, However my meaning of complete was more in respect to the phrase "The complete man"

Now does that phrase mean, "The man is dead"?. The death meaning may apply more to the term "finished" but less to "Complete". And also agree with the "wait untill.." I will use rakudo or other implementations of Perl 6 for a throw away script. But how do you expect that to be a "Complete" product for a production environment and for all such purposes where we want to sell Perl 6 to our bosses. We certainly can't sell it as a "Complete" product in the same sense we sell Perl 5 as a "Complete" product.

Do you know of any software that is both alive (ie actively developed) and "completed"?

IMO, there's a difference between being "alive" and "actively developed".