in reply to Re: Translating Perl5 to Perl6.
in thread Translating Perl5 to Perl6.

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.

Replies are listed 'Best First'.
Re: Re: Re: Translating Perl5 to Perl6.
by Elian (Parson) on May 07, 2002 at 14:38 UTC
    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.
[reply]
[d/l]
[select]

In Section Meditations