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