Beefy Boxes and Bandwidth Generously Provided by pair Networks
laziness, impatience, and hubris
 
PerlMonks  

Translating Perl5 to Perl6.

by vladb (Vicar)
on May 06, 2002 at 20:03 UTC ( [id://164426]=perlmeditation: print w/replies, xml ) Need Help??

Reading through the Parrot Answers page, I came across this intriguing question:

12) p52p6 by rafael

Have you an idea about the implementation of the "official" p52p6 translator ? OK, that's not really Parrot-related. Just to know how you feel about this.

Yep, I've thought about it. There are three ways to go about it, and we're likely to use all three.

  1. A B::Parrot module that turns a perl 5 optree to Parrot bytecode
  2. The Perl 5 parser/lexer/tokenizer code on a Parrot back end
  3. A native perl 5 parser module for Parrot.


That's likely the order we'll take them in, too.



Also, looking at the perl6-update file, I find piont 5 that is related to this question:
5) Clean up the language
  . . .
  - Perl5 to Perl6 compiler?
    - Automatic translation
    - 100% translation for 80% of Perl programs
    - 95% translation for 95% of Perl programs
So, from what I've seen so far (and quite understandable) I can't expect to be able to seamlessly translate all of my Perl5 scripts over to Perl6 code? On average, there should still remain 15%-20% of legacy code that I'll have to worry about on an individual basis and invest extra time to manually upgrade this code to Perl6.


Since work on the Parrot and, consequently, Perl6 is well underway, I think it is time for me to start asking these questions. Should I write my code such that it could be easily translated to Perl6 requiring only minimal 'manual labor' (getting inside the code and changing things on my own :)? In which case, how do I know the part of Perl5 that couldn't not be properly translated into Perl6? I realize that there's a lot of places where one could read more on the specifics of the new Perl language. The first thing that springs to my mind are the Apocalypse series by St. Larry Wall. There, I learn, for example, that the first thing to be dropped in Perl6 are the typeglobs. Does this imply that I should try as hard to stay away from relying too much on the use of typeglobs in my code? Or, can I still safely use them knowing that they could be easily translated in a Perl6 variant. I guess I wouldn't know the answer until I try initial releases of such a translator, eh? But will it be already too late by the time it's released?

I hope that I didn't sound too hysterical in this post. Do you have similar fears about your legacy code? My worry is I may have to spend more time than I could possibly get (there's only so much time allotted to 'maintenance' at my place of work ;/) to upgrade my legacy Perl5 code to the new Perl6 format.

Please bring on the discussian! ;-)).

Cheers,

- vlad.

"There is no system but GNU, and Linux is one of its kernels." -- Confession of Faith

Replies are listed 'Best First'.
Re: Translating Perl5 to Perl6.
by Elian (Parson) on May 06, 2002 at 20:20 UTC
    If you want perl 5 code that translates properly, try avoiding the following things (keeping in mind that this is a paranoid list and may well be overcautious)
    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)
    There are probably other areas that things'll be different, but those are the biggies.

    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;
        will work just fine when translated to perl 6, I'm just not sure I want to guarantee that
        *foo = *bar;
        will get everything the way we might like, at least if you're doing some of the odder things.
Re: Translating Perl5 to Perl6.
by chromatic (Archbishop) on May 07, 2002 at 02:01 UTC
    Perl 5 won't immediately go away when Perl 6 is released. I'm not avoiding important features because I don't know if I'll have time to revise them. I'm in favor of incremental maintenance anyway.

    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.

Re: Translating Perl5 to Perl6.
by dreadpiratepeter (Priest) on May 06, 2002 at 23:32 UTC
    According to everything I heard Larry, Damian, Simon, and Dan say at last years Perl conference, the Perl6 compiler will run Perl5 as well. There is no need to translate legacy code, unless you want to.

    -pete
    "Pain heals. Chicks dig scars. Glory lasts forever."
Re: Translating Perl5 to Perl6.
by Juerd (Abbot) on May 07, 2002 at 10:55 UTC

    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.
    

Re: Translating Perl5 to Perl6.
by Mr. Muskrat (Canon) on May 06, 2002 at 20:17 UTC

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


    Matthew Musgrove
    Who says that programmers can't work in the Marketing Department?
    Or is that who says that Marketing people can't program?
Re: Translating Perl5 to Perl6.
by BUU (Prior) on May 06, 2002 at 20:08 UTC
    im vaugely concerned about trying to run code on some perl6 servers and some perl5 servers, as most of the 'proffessional' webhosts may not upg perl for a while.. So what do you do? Write two versions? Try to write perl5 that works in perl6?

      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.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://164426]
Approved by ignatz
Front-paged by rinceWind
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others cooling their heels in the Monastery: (4)
As of 2024-03-29 10:42 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found