use Perl

• Perl 6, Parrot, Rakudo. (Score:1)

  by scrottie (4167)

  I didn't reply before because I didn't have to contribute what you're looking for, but I was pointed at this again today and you've only got one reply... so... here goes.

  The Exegesis and so on are pretty good. It's hard to say how complete they are until people have been using an implementation of it for a while. That's the nature of the beast. You don't know how much further until you get there, and in this case, that's a function of observing people use what you've made for a while.

  The (I forgot what i
  • Re:Perl 6, Parrot, Rakudo. (Score:1)

    by chromatic (983) on 2009.01.08 4:49 (#66759) Homepage Journal

    [People] looked at Perl 5 and said, "We can do better". That's the wrong kind of hubris.

    Anyone who's patched Perl 5 and hasn't thought "We can do better" has insufficient imagination.

    No one helped Audrey. Or few people did.

    I tried. Pugs was unusable. This approach did not work. Note that for any perceived or real flaws in the Rakudo approach, it makes visible progress toward its goals every week, and visible, dramatic progress in every stable monthly release.

    Perl 5 has a runops and pp_hot.c that fits nicely in a moderately sized cache.

    It's funny that you mention this right before talking about optimizing based on speculation and intuition. To my knowledge, no one's profiled pp_hot.c to see where the functions end up and whether the PP codes in that file are actually the hotspots in modern programs. At least, no one's profiled real programs that way in years. (If you really want to make sure all of this code fits in the cache, figure out some way to pull all of the magic-checking code out of individual PP codes, so they can be substantially smaller.)

    By the time they're done, the LLVM is out and does a good job of this and the problem is obsolete.

    Y'know, I've known Chris Lattner since his undergraduate days, before he had the idea of LLVM, and certainly before he'd given up on GCC. Some of the Parrot hackers do keep up on the state of the art, at least enough to say that LLVM and Parrot have very different goals.

    It's impressive that [Rakudo] as far along as it is.... But that's the dumbest way to bootstrap I've ever heard of.

    Rakudo's never had VM bootstrapping as a goal. Thus I'm not sure why it's an interesting criticism that it handles VM bootstrapping poorly.

    Still, if Perl 5 is able to parse Perl 6, more and more of the Perl 5 that parses the Perl 6 can be moved into C. There are various other options -- options that are incremental and save optimization for last, if ever.

    Before Pugs went on hiatus, it took a work day for me to run the complete test suite. Sometimes you can't ignore optimizations.

    gimmie5 effectively fits this BCPL->B->C model, but the waters are muddled a bit by Perl 5 not being self hosting.

    Sure, and all you have to do to make control flow or laziness or iterators or parallelizing hyperoperators work in a Perl 6 bootstrapped on Perl 5 is either rewrite Perl 5's control flow from runops upwards or build a large chunk of Parrot in Perl 5.

    I once wrote a patch to make resumable exceptions work in Perl 5. One reason it's not in Perl 5.10 or 5.11 is that making it work reliably with Perl 5 scopes and their C-level destruction of temps allocated within the optree itself is very, very difficult. It's not impossible, but the practical possibility of making it work requires refactoring a lot of Perl 5's internals, which probably means breaking a lot of CPAN and DarkPAN modules, because Perl 5's internals have never had encapsulation.

    Add laziness to my hubris for that.

    [Let's] say Parrot were a pure stack machine. Then the call convention debates would be almost non-existent.

    Except for optional parameters, multi dispatch, named parameters... but flat/slurpy parameters are fairly easy. Did you know that LLVM's a register machine too?

    In short, even if Parrot flies, it's going to be a bigger pile of crap than Perl 5....

    Let's make a gentlemen's wager. I dare you to add a new feature to Perl 5 and the same feature to Rakudo. Which is easier? (I've done both. Does that mean I'm poisoning the well even bringing up this idea?)

    Don't misunderstand. There are plenty of parts of Parrot I don't like -- and the Piethon contest was a mistake which hurt the project. I don't think your criticism are accurate, though.

    Reply to This

    Parent