The right time to start a project? made me wonder whether there is a repository of "Do's and Don'ts in Perl 5" that would facilitate a future migration to Perl 6? Something you could look at if you're starting a new Perl 5 project?

I realize that there are a number of Perl6:: modules out there already, but I would understand it if you wouldn't want to use those in production code.

I'm more thinking along the lines of:

Is there such a repository already? If not, would it make sense for the Perl Monks to create and maintain one?

Liz

Summary:

  1. It seems the general consensus is that such a repository is not needed now (or ever for that matter).

  2. It is generally advised not to use XS or Inline::C (if you must, then only use Perl 5 macro's).

  3. Don't do anything Abigail-II is doing in JAPH's ;-)

  4. Don't use %_ .

  5. Don't use the X:: namespace.

Replies are listed 'Best First'.
Re: Perl 5 -> 6 do's and don'ts?
by Abigail-II (Bishop) on Aug 01, 2003 at 09:46 UTC
    Considering that the language specification hasn't been finished, and they are still changing things from older apocalypses, isn't it a bit too early for that? I don't expect perl6 to be there any time soon, if ever.

    Furthermore, we were always promised that perl6 would be able to run perl5 code, so there isn't a pressing need to translate perl5 code to perl6.

    Having said that, I've some points for you:

    • Don't use XS code.
    • Don't use modules that use XS (like DBI and Tk).

    Abigail

[reply]
      Don't use XS code

      From what I have read about the recently announced Ponie project - we will now be able to port XS code over to run on Parrot. From the Ponie FAQ:

      The guts of Perl 5 will be ripped out and made to work using Parrot PMCs rather than Perl 5 Sv structures, which will mean it will be compatible with Perl 6 . Any XS-based code that uses the published Perl 5 API should work fine without any problems. Anything that was marked for deprecation in Perl 5.8.0 will be deprecated in Ponie.
[reply]
      Does that imply that using Inline::C as opposed to XS would be a good choice now?

      Liz

[reply]

        I'll somewhat disagree with Abigail-II and Elian.

        Yes, if you want to interface Perl5 to a C library, then doing so via Inline::C is more likely to make it easy to port to Perl6 than using XS would (the XS porting might be available sooner, but you have much more risk of doing something that won't be handled if you use XS, IMHO).

        Using Inline::C or XS to manipulate Perl data structures is something I simply don't recommend and I find that avoiding it when interfacing a library usually makes for a better design anyway.

        C code that manipulates Perl data structures has always been the first thing to break when Perl is upgraded. So asking how to do that with Perl6 in mind calls the answer "Don't!" to mind (which is my answer anyway, just not as emphatically).

        So when someone asks how to use XS with Perl 6 in mind, my advice is "Don't manipulate any Perl data structures in C and use Inline::C instead of XS." But, that is my advice anyway (again). And I'll bet that modules that follow that advice will eventually be able to work with Perl 6 without requiring any "by-hand" porting.

                        - tye
[reply]
        Considering that Inline::C is just a layer over XS, I don't think so. (And can Inline::C already deal with modules using C?)

        Abigail

[reply]
        No, it doesn't. The issue, such as it is, is with perl's API. XS is just a thin and somewhat brain-damaged macro layer over C, as is Inline::C. (Which, granted, is far less brain-damaged)

        Any non-specious reason to not use XS applies to Inline::C as well.

[reply]
      I don't expect perl6 to be there any time soon, if ever. In fact, it may have to be named Perl 7 or 8 if we keep maintaining the 5 tree at the rate it is going.

      Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

[reply]
[d/l]
Re: Perl 5 -> 6 do's and don'ts?
by TimToady (Parson) on Aug 02, 2003 at 01:37 UTC
    Probably the biggest thing in my mind is that you shouldn't rely on the current dynamic scoping behavior of $_ because it'll be lexically scoped in Perl 6. Anything that uses select is also highly suspect.
[reply]
[d/l]
[select]
      I presume you mean 2-arg select, or is 4-arg also going the way of the dodo?

      --
      I'm not belgian but I play one on TV.

[reply]
        We would already have deprecated 4-arg select if we had anything decent to replace it with. Filehandles aren't well represented by small integers in Perl. Indeed, some filehandles map to more than one file descriptor underneath. Filehandles (and all other event-producing entities) need to be tied together with a consistent event-handling model.
[reply]
Re: Perl 5 -> 6 do's and don'ts?
by adrianh (Chancellor) on Aug 01, 2003 at 09:56 UTC

    Personally, I don't think it's worth worrying about yet. The Perl6 language is still in flux so guesses made now may be incorrect six months down the line. Also Ponie, I would imagine, will remove most of the porting problems completely since it should be possible to call Perl5 code (including XS) from Perl6 in the same interpreter.

    (Also, AFAIK, formats aren't disappearing from Perl6 - they're just moving from the core language to a module.)

[reply]
      (Also, AFAIK, formats aren't disappearing from Perl6 - they're just moving from the core language to a module.)
      Correct. However the syntax and semantics of the formatting facilities provided by that module will also differ from those of Perl 5 formats. See the Text::Reform module for a foretaste of the new approach (though Perl 6 formats will also differ somewhat from the syntax and semantics that module currently provides)
[reply]
      I agree I think Perl6 is just a myth, just a rumour of greener grass. a gentle whispher of idealogy floating in the summer wind. In my opinion the community process gives high quality but slow progress.

      they should just join the Apache ranks or do it like the Mysql folks and set up an open source company for it.

[reply]
        I agree I think Perl6 is just a myth, just a rumour of greener grass. a gentle whispher of idealogy floating in the summer wind.

        Tell that to the people who are actually working on it. If you're going to play armchair Perl hacker, at least tune in once in a while.

        they should just join the Apache ranks

        And that would help, how? Will the magical Apache Hackers do all the development for them?

        or do it like the Mysql folks and set up an open source company for it.

        So the most excellent people actually doing the work (as opposed to you) should give up the their own money and the little time they have to start up a company, with basically 0 chance of profitability? And this will get Perl 6 into your highly deserving hands faster, how?

        Just because Perl is OSS doesn't mean it magically appears out of the void. People have to spend a lot of their time developing it and get virtually no compensation in return. How do you think it helps to state their work is just a myth? Get contributing, or get out of the way.

[reply]
Re: Perl 5 -> 6 do's and don'ts?
by Elian (Parson) on Aug 01, 2003 at 13:19 UTC
    The only real "don't" is Don't use any odd perl behaviour that only expresses itself in one of Abigail's JAPHs. Beyond that, it doesn't much matter.
[reply]
Re: Perl 5 -> 6 do's and don'ts?
by liz (Monsignor) on Aug 01, 2003 at 22:19 UTC
    For all of you (considering) using %_, this just in from p5p by TheDamian:

    From a Perl 6 perspective, it seems likely that C<%_> will be the name commonly used for the "slurpy hash" of a subroutine. Just as C<@_> will often be the name used for the "slurpy array". See Exegesis 6 for more details.

    Indeed, when it comes to object constructors (all of which implicitly have a slurpy hash), C<%_> might well be the automatically provided name for that hash. See Exegesis 12 for more details. ;-)

    Hence, making C<%_> mean something different in core Perl 5 might possibly be "forwards incompatible"

    Liz

[reply]
Re: Perl 5 -> 6 do's and don'ts?
by dga (Hermit) on Aug 01, 2003 at 22:44 UTC

    I was going back and reading the Apocalypses and found another thing not to do in preparation for Perl 6.

    Larry wants to take the X:: at the top level for Exceptions. From Apocalypse 4:

    But in any event, I can't imagine getting people to prefix every exception with "Exception::". That's just gonna discourage people from using exceptions. I'm quite willing to at least reserve the X top-level class for exceptions. I think X:: is quite sufficiently distinctive.
[reply]
      If it weren't invalid/so hairy to parse I'd propose ! as the exception namespace ;-)

      --
      I'm not belgian but I play one on TV.

[reply]

Back to Meditations