After much socialtechnical discussions and hackings, the shiny Pugs::Compiler::Rule and Module::Compile are finally upon us! fglock++ and ingy++ for tirelessly working with #perl6 people, almost non-stop, for the past 48 hours.
There is still a long way to go for Pugs::Compiler::Rule, but it's shaping up to be a promising start. The Perl5-based Perl 6 compiler in the pX/ tree is already moving forward after the release of the Rule engine -- in particular, ruoso++ is is refactoring .pl files into proper .pm modules in the lrep-compiler subtree, similar to how iterator_engine.pl was refactored out to Pugs::Compiler::Rule.
As for Module::Compile... for a general overview of what it is good for, and some of the socialtechnical issues around it, please see my post on perl5-porters and Juerd's excellent overview on perlmonks. I'm really excited about a saner drop-in replacement to source filters so we can cleanly extending the Perl 5 language in a composable fashion.
During the discussion of Module::Compile on #p5p, certain very crazy folks suggested a possible "goto *FH" form for Perl 5.10 to simplify the control transition between .pm/.pmc, or anything that needs to transfer control over to other files -- i.e. eval_exec. It is certainly a very perlish, very golfy, very wacky suggestion... Not sure whether it will make into the core or not.
On the Parrot front, today I continue to discover segfaults for Leo to fix, learning quite a bit about gdb and valgrind along the way. Happily, we discovered that all the Perl 6 semantics required by the object space bootstrapping code can be encoded into PIR; I've scribbed down some notes to be translated into a much improved Emit.PIR tree tomorrow.
There is some interest underway from gaal++ and mugwump++ to machine-translate Haskell structures into Perl 6, so we can export all the Pugs/Haskell data definitions (such as Emit.PIR), then encode the same logic into Perl 6, with its rather powerful structural pattern-match syntax for writing compilers and emitters. That may prove to be very useful for the gradual transition toward full self-hosting.
That's it for today... See you tomorrow! :-)
i'm almost starting to get confused here. once again, great posts audrey. BUT i am starting to get a little dizzy and can't fully grok:
- what current perl6 syntax pugs supports
- what current perl6 syntax itself is frozen
- how far we need to go with pugs
- the who/what/where about cutting over to parrot
- how exactly the perl5 filter fits in
in other words, i need to be de-idiotized with a state of the onion (but a real state of the onion, not the usual comedy routines larry puts on), and i suspect lots of other people do too.
Posted by: grumpY! | 2006.03.14 at 02:22 PM
I belive, nothing is really 'frozen'? but some parts (flow control, function definition/call syntax, rules, OO) are less likely to change than the others (marcos). Some things are underspecced/unspecced (threads, builtins, embedding, distro/libraries).
Most work is now concentrated on bridging the gap between Pugs/lrep (parsers/interpreters, 'high level' implementations of P6) and Parrot 'the VM'; and bootstrapping (by moving Pugs/lrep infrastructures gradually from Haskell/p5 to p6).
That's what I gather from blogs here and lurking on perl6-* lists.
Posted by: kaa | 2006.03.14 at 05:41 PM