A tale of two PMCs.

Just some short sketches as I'm quite exhausted after another day of nonstop hacking.

Ingy and I generalized the "use v6-pugs" concept into Module::Compile, taking advantage of Perl 5.6+'s feature that when you say "use Foo", it looks first at the Foo.pmc file, and only if it's stale or nonexistent (which is, like, always), will it load Foo.pm.

See fglock's ongoing work on Pugs::Grammar::Rule for the zeroth application of this idea -- Rule.pm is processed on author's side, and Rule.pmc is uploaded/installed along with it, so the user won't need a copy of pugs, or an installed version of v6.pm -- it's all just pure Perl 5 code.

This is wonderful news, as it solves four major problems for source-filterish technlogies like Inline, Spiffy, Switch (and of course, v6):

• The user doesn't need to install the filtering modules themselves; the .pmc code is precompiled into normal Perl 5 code.
• Debugging is now much easier, as you have both the original and transformed programs available.
• Embedded Perls (say in mod_perl) can load them without triggering INIT problems, as the .pmc are just regular Perl code.
• Finally and most importantly, this makes source filters composable, and you can have nested chunks of layered compilers inherits or delegates to each other. This is great for eg. porting the Perl 6 macro system to Perl 5.

As a consequence, the release of v6.pm and Pugs::Compiler::Rule has been delayed for one day, so that we can have more robust cross-validation between .pm and .pmc files, and have them play nicely with other Module::Compile technologies.

In other news, Leo and I populated the languages/pugs/ tree in Parrot, bringing in all the Value PMCs we need for bootstrapping PIL^N on Parrot. We just need to figure out Pad/Namespace storage and primitive mappings, and we'll instantly get a running Perl 6 object space -- with Classes and Roles -- on top of parrot.

The porting of Value PMCs largely involves finding a base PMC type and extend from it, although Parrot's notion of treating all PMCs as scalar/array/hash/sub/ref containers means we'll get some oddities in the object model:

• "1.id == 1.id" doesn't hold, as two boxing attempts always produce two PugsInt objects
• "int('12345678901234567890')" overflows, as PugsStr cannot coerce to PugsInt, and always have to go through a native I register (which is limited in size)
• "given 1 { $_++ }" won't throw an exception, and will indeed silently change the "1" in-place!

It'd make more sense if a PMC can declare that it's not a container at all, and avoid the FETCH/STORE type vtable entries altogether, or at least declare it only supports one container interface or the other. I've submitted an overview on perl6-internals as well.

That's it for today. See you tomorrow!

Comments

[grumpY!]

these posts make great reads, keep them up, it lets people know there is some momentum.

[Juerd]

Thanks again for writing in a language that outsiders can understand. The information in #perl6 tends to be a bit too dense and consise, and you're very good at transliterating it.