Re^3: Backend diversity for Rakudo

... 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.)

Comment on Re^3: Backend diversity for Rakudo

Replies are listed 'Best First'.
Re^4: Backend diversity for Rakudo by moritz (Cardinal) on Aug 17, 2010 at 18:16 UTC
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.	[reply]
Re^5: Backend diversity for Rakudo by Corion (Patriarch) on Aug 17, 2010 at 18:33 UTC
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.	[reply]
Re^6: Backend diversity for Rakudo by BrowserUk (Patriarch) on Aug 17, 2010 at 19:53 UTC
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. That's my conclusion also. Too little, too late.	[reply]
Re^7: Backend diversity for Rakudo by chromatic (Archbishop) on Aug 17, 2010 at 20:41 UTC
Re^8: Backend diversity for Rakudo by BrowserUk (Patriarch) on Aug 17, 2010 at 21:13 UTC
Some notes below your chosen depth have not been shown here
Re^8: Backend diversity for Rakudo by Corion (Patriarch) on Aug 17, 2010 at 21:05 UTC
Some notes below your chosen depth have not been shown here
Re^6: Backend diversity for Rakudo by chromatic (Archbishop) on Aug 17, 2010 at 18:53 UTC
It's a bit sad that nobody seems to share my view on the Perl 6+Parrot teams, at least enough to push the issue. I share your views. Anyone interested in working on this has my full support.	[reply]
Re^5: Backend diversity for Rakudo by chromatic (Archbishop) on Aug 17, 2010 at 18:50 UTC
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.	[reply]