Diagram for Perl 6's CPAN stack.

With #perl6's help (in particular from putter++ and TimToady++), I have converted the layers from yesterday's bullet points into this diagram (click to zoom in -- thanks to Gordon McCreight for the thumbnail).

The Perl 5 Sugar layer is really key: it ensures that CPAN authors can use the relatively stable Perl 6 semantics without worrying about the more experimental Perl 6 syntax, and also ensures that v6.pm generates idiomatic Perl 5 code as output.

Each layer depends only on the layers below it. Everything above the XS layer will be pure-perl and hence very portable. The XS layer currently depends on some underdocumented areas of perl core (PL_check, for example), and we'd like to document them and bring them into the core regression test suite, so that they become fully supported in the future.

The diagram currently only lists existing modules, so there are a lot of "..." to be filled in each layer -- in particular we need sugar for all of semantic-layer modules -- but that's an exercise for tomorrow. :-)

Comments

[rgs]

I'd like to emphasize that I'm willing and ready to help with whatever needs to make the P5 core ready for use as the basis of this stack. P5P waits for your desires and contributions!

[ian b]

Is Pugs::Compiler and Pugs::Runtime pure perl?

I'm confused because I thought those involved some haskell, and you have them in this diagram above the XS layer -- which means that they are actually pure perl...

[Audrey T]

Ian: As CPAN modules, they are now pure perl; what we are doing is synchronizing Haskell-side modules with Perl5-side modules, make them implement a common API and a common Perl 6 AST, so you can switch between two "Pugs" runtimes and get the same semantics.

So indeed, you do not need GHC installed to use any of it.

[Bártházi András]

Audrey: so as I know it means: Pugs now have more than one backends (runtimes). The planned was Parrot, the first was Haskell and now, as I know, there are Parrot, Haskell, JavaScript and Perl 5. But that's all my knowledge - what are the state of these backends? Are they fast? Which is the best in speed, in knowledge? As I see, it would be a great idea to create a matrix about speed and knowledge for the non-lambda-camels :). As I just read your blog and sometimes looking around, I have no information about these questions, and I think somebody++ should clarify it.

[Confused]

What are the main obstacles remaining in Parrot to have it supported as a first class Perl6 back end as is Haskell? Would Neko be a better target for Perl6?

[Audrey T]

Confused: It needs a sane exception handling mechanism, distinction between container and value objects, a method dispatch system that allows inspection over the dispatch chain, a multi dispatch system that works with preferential resolution instead of Manhattan resolution, reflection API for the class system, to name a few.

It'll eventually get there (and I'm doing what I can to help), but currently the churn is still very, very high...

[Confused]

Requiring the VM to have working exceptions and support reflection is understandable, but why burden the VM with dispatch chain inspection and multi-dispatch? Perl5 lacks these features, after all, and they must be emulated at the library level with appropriate data structures. Where do you draw the line as to what functionality is in the compiler/generated code/supporting library and the VM? Shouldn't the VM requirements be as modest as possible so that Perl6 can be easily retargetted?

[Audrey T]

Confused: Yes, but the thing is the multi dispatcher, although it's possible to be written out in pure Perl6, would still require dispatch chain inspection to work in any efficient manner.

In the simplest case it's just a "super;" call, which is present in Ruby/Python but _not_ Perl5 (though we emulate it there in Moose). However, even that call is missing in Parrot. :)