On Fri, Mar 25, 2005 at 10:27:53PM +1100, Adam Kennedy wrote:
: Also, I saw another mention recently (possibly on TPF request for 
: donations) about the Perl 5 to Perl 6 converter, and it being 40% 
: completed? ... Larry?

Well, by one reckoning it's 0% done.  At the moment I'm just working
on a Perl 5 to Perl 5 converter.  When I get that right, I can start
on the Perl 6 converter.  It's quite likely I've already done 40%
of the work, though.

: Is anybody working on it? If it's built on something other than PPI, is 
: there anything I can see, so I can steal any parsing tricks I don't know 
: of yet. :)

Er, I'm not sure you will want to--I'm using PPI's evil twin brother,
"PPD" (the actual Perl parser).  I've just modified it so it doesn't
forget anything I want it to remember.  (As you know, the standard
parser throws away gobs of useful information, everything from
whitespace and comments to pruned opcode subtrees.  I have a version
that doesn't do that, by and large, though I'm still finding fiddly
spots.)  When it's done parsing, it can spit out all the information
in rough-and-ready XML.  From there I've currently got two passes, one
to turn the XML into an AST very much like what PPI uses, and another
to turn the AST into whatever the target language is, Perl 5 for now.
When I can run any (un-source-filtered) Perl 5 program through it and
get the exact same program out, including whitespace and comments,
then I'll know I have a good platform for translation to Perl 6.
Essentially I'll be 80% done at that point, and ready for the next 80%.

Doing a literal translation to Perl 6 won't be terribly hard, except
where we've actually removed things that were in Perl 5, but we can
always emulate any features that are missing, probably pulling them
out of some EVIL::PERL5::EMULATION module to discourage people from
using the emulations in new code.

Source filters are always going to be a problem, but if we translate
the underlying standard Perl 5 code (which is what my current setup
will do), it should at least run, if not produce good looking code.
We can look at the existing source filters on a case-by-case basis
and perhaps install recognizers that refactor the ugly code back into
something more like the pre-source-filtered code.  Most of the hard
work in the second 80% is going to be in figuring out how (and whether)
to refactor Perl 5 idioms into Perl 6 idioms, particularly for OO stuff.

We can probably arrange not to duplicate the back-end refactoring
work, if we can get our respective ASTs to line up.  But I do think
the front end of the "standard" translator must be based on the actual
parser they're using.  I'm sure there's plenty of room for alternate
approaches, though.  There might be classes of lightly-source-filtered
programs that PPI would translate better than what I'm working on.

But what I've got isn't ready to release even in preliminary form.
I'm still tweaking too many things in parallel along the whole chain,
and the design is still doing cartwheels occasionally.  Anyone else
working on it would have to have an interest extending from the
insanity of Perl 5 parser internals all the way to various deep Perl 6
design issues, and I don't think anyone else besides me has the
requisite multiple personality disorder.

Hmm, that sounds like I'll never release it till it's perfect.
It's really only the p5-to-p5 part that has to be close-to-perfect,
but it's a really easy target to test for.  I figure the translator
can go alpha when it can do the wooden literal translation, and we
can then do all the refactoring work in parallel.  Or I might figure
out an earlier point where I could use people's help.  Right now
it would just be a distraction, though.

Unfortunately, I don't have a lot of spare time to work on it these
days because of having to put bread on the table.  And quite apart from
the bread, I am deeply indebted to many people for letting me design
Perl 6 for the last several years--but I mean that all too literally.

As the bumper sticker says: I owe, I owe, so off to work I go...  :-)


Reply via email to