1. Typeglobs (maybe)
2. Odd syntactic corner cases (Like some of the JAPHish things)
3. Version specific behavior (hash ordering)
4. Numeric size assumptions (32-bit ints, # of bits in a float mantissa)
5. Low-level interfaces (like the raw source filter interface, not what Filter::Simple provides)
6. Ordering of operations at undefined points (like when $foo = $i++ + $i++ increments $i)

XS code, of course, is in for a rougher time, but that's a separate issue. And it may turn out that these warnings are at least in part overly paranoid.

It seems that all your 6 points here are good programming practice as a matter of course.

1. Typeglobs (maybe)

   There are some circumstances when messing with stashes, for example, when typeglobs are unavoidable. However, These bits of code can probably be written much cleaner in Perl6.

2. Odd syntactic corner cases (Like some of the JAPHish things)

   Avoid unless obfu-ing or golfing. These are certainly defeating the aim of code clarity.

3. Version specific behavior (hash ordering)

   is asking for trouble anyway.

4. Numeric size assumptions (32-bit ints, # of bits in a float mantissa)

   defeats the aim of portability.

5. Low-level interfaces (like the raw source filter interface, not what Filter::Simple provides)

   OK, but why re-invent the wheel anyway?

6. Ordering of operations at undefined points (like when $foo = $i++ + $i++ increments $i)

   yyeughh! Need I say more.

I should point out that none of the points were listed because they were bad programming practice. (I'm worrying about cache line spills and writing assembly code--bad perl programming practice is just not a concern :) I listed them because they all take advantage of what could be considered "interesting aspects" of the perl interpreter engine, aspects that we're not preserving in their entirety (or at all) in Parrot.

Having said that, it's really likely that things like:

*foo = \$bar;
[download]

will work just fine when translated to perl 6, I'm just not sure I want to guarantee that

*foo = *bar;
[download]

will get everything the way we might like, at least if you're doing some of the odder things.

Besides that, I suspect that smart people like Rafael will be making good progress on B::Parrot. Bytecode's much easier to manipulate than raw code.

Use as much pure-perl as you can, and avoid low-level activities at all cost. Do not anticipate given/when using a Filter, because filters only reduce the chance of having a good conversion.

Try downloading the Perl 1.0 sourcecode, that was released in 1987. You'll be amazed to see how many tests are succesful if you run them with Perl 5.6.1. That is mostly because the code is written simple and clear. The tests that don't succeed all have to do with things you want to avoid anyway, like weird variable names ($  (dollar space)), goto LABEL and some minor language incompatibilities that I don't understand (it seems that Perl 1.0 subs return undef if their last statement is conditional and never executed).

Someone else has already mentioned things you should avoid to ensure easier conversion. Anyhow, write clear pure-perl code, in a good style - make sure that you don't do things that "happen to work". If you have some spare time, write tests.

Oh and use strict, especially when writing modules.

- Yes, I reinvent wheels.
- Spam: Visit eurotraQ.

I can see it now:
Perl 5 vs Perl 6!
And you thought the NS vs IE debate was bad...
:D

We have this same problem with Perl 4, truly. And Perl 5 which isn't 5.6. These are issues which Perl 6 culturally is set out to handle, such as convincing webhosts that Perl isn't any good without a large module base. It's not a new issue, and certainly one we all think about.

Cheers,
Erik

Update: s/with/without Woops. Thanks premchai21.