On Sat, Mar 26, 2005 at 06:49:58PM +1100, Adam Kennedy wrote:
: >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.) 
: So I'm presuming that you don't intend this as a tool that can do mass 
: porting of code (due to the dependency issues), but rather as something 
: for helping individual module authors port individual files/modules.

With the existence of Ponie, my hope is that people can port things
piecemeal and retest for regressions at every stage along the way,
presuming they have something that actually has regression tests.
I think "translate everything and hope for the best" is a recipe
for disaster on any project larger than one person's head.

That being said, there's nothing that says the translator has to
support only one kind of output, which means there's no reason
you can't have some kind of overall policy driving the individual
translations, so I don't see why dependency mapping should be a
big problem.  It just forces your translation granularity to chunks
of modules that require the same support, when that support is of a
nature that can't be split between Ponie and Perl 6.  Only in the limit
does that mean you have to translate everything all at once, and you'd
still probably want some kind of overall policy file to control it,
if only so you can tweak it and try the whole mess some other way.

: Also curious how you handle BEGIN and friends... I take they are 
: executed and then pruned, and end up unpruned in your XML?

I just intercept the op_free() routine with another routine that knows
where to store the op tree that was about to be freed, to the first
approximation.  I also install null nodes in the tree as "pegs" to hang
the exact location of declarations like BEGIN, use, subs, etc.

: Also curious if you have managed to keep comments, POD etc...

Certainly.  It takes MAD skills, where MAD stands for Miscellaneous
Attribute Decorations.  (Doing anything with toke.c requires madness.)

Well, actually, speaking of doing things piecemeal, I haven't tested
the POD part yet, just the comments.  And I'm quite sure I haven't
captured the __DATA__ yet, but that'll have to happen too.  But conceptually
it's all there.  :-)

The thing is that these MAD props are hung on whatever node is handy at
the time, which might be the token before, but usually is the token after,
but usually *wants* to be somewhere up higher in the tree that doesn't
exist yet.  The changes to Perl internals are intentionally very minimal
so as not to influence parsing behavior more than .5 iota, so I don't
try to do any tree rearrangement in the parser.  The XML is just the
raw dump of the tree with its misplaced madprops.  That's the main
reason for the first pass of translator, to reattach the madprops
at a more appropriate place in the tree.

Interesting issues arise, such as deciding when a comment goes with the
previous code and when it goes with the next code, or when you just
stick it into the interstices for now.  At the moment my tendency is
to hoist leading and trailing whitespace into the interstices of the
higher list when that's practical.  But with comments you'd like them
to travel with the code they're commenting, in cases where refactoring
moves code around.

The basic problem is that there's no one level that's right to do
the translation.  You have to take into account both shallow and
deep information and everything in between simultaneously, because
all of those things are important to the programmer at some point.
I'm aiming for a deeply correct translation that tries to preserve
as much surface detail as possible, but when push comes to shove,
it's the surface detail that has to get shoved, even if that screws
up their pretty formatting.  The nice thing about a deep translation
is that you can know when you're guessing, and at least mark it
so the programmer can double-check the translation.  A surface-level
translator is always guessing, and doesn't always know it.  I dare
say most Perl 5 could be translated to Perl 6 with a series of s///,
but it always be getting stupid just when you want it to be smart.

Gee, it looks like you found my hot button, or at least my warm button.
Maybe I should work up a talk about all this someday...


Reply via email to