Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Perl Programming

Ponie: Perl On New Internal Engine 47

Posted by timothy from the clopclop-clopclop dept.
caseywest writes "Today at his State of the Onion speech during the 2003 O'Reilly Open Source Convention, Larry Wall announced the Ponie project (somewhere within his legendary humorous presentation). Ponie involves rewriting central parts of the Perl 5 interpreter to run on Parrot, the Perl 6 virtual machine, including a C API emulation layer to make existing XS code work. Arthur 'sky' Bergman is sponsored by his employer Fotango to develop Ponie. Currently, a press release and a FAQ are available. More details will be available in due time."
This discussion has been archived. No new comments can be posted.

Ponie: Perl On New Internal Engine More

Ponie: Perl On New Internal Engine

Comments Filter:
  • This is all just a plot to get tickets to YAPC::Europe [yapc.org]
    And a damn good one too, i'm going. Hope we'll get some scoop on this too
    One year has passed since the last YAPC and they defenately confused me enough to make me want to hear The Damian [perlmonks.org] explain it to me all over again, or anyone who understands it for that matter ;)
    Funny how he won over the complete hall of coders using only two words: "less chars"
  • The proof is in the CPAN [cpan.org]:

    David Cantrell > Acme-Pony-1.1.2 > Acme::Pony
    Module Version: 1.1.2 Source

    NAME
    SYNOPSIS
    DESCRIPTION
    DIAGNOSTICS
    AUTHOR
    COPYRIGHT

    NAME
    Acme::Pony - An encoding scheme for Silly People

    SYNOPSIS
    use Acme::Pony;

    print "Hello world";

    DESCRIPTION
    The first time you run a program under use Acme::Pony, the module removes all that nasty text stuff from your source file, turning it into a lovely ASCII-art rendition of a pony. In the spirit of other london.pm modules, the ASCII-art will consist entirely of the characters matching /[buffy]+/i, thus fulfilling Greg, Leon and Dave's fantasy of seeing Buffy riding a Pony.

    DIAGNOSTICS

    Can't pony '%s'
    Acme::Pony couldn't access the source file for modification.

    Can't unpony '%s'
    Acme::Pony couldn't access the source file for execution.

    AUTHOR
    David Cantrell

    This is based on Leon Brocard's 'Buffy' module and inspired by Damian Conway's brief talk on his Bleach module.

    Leon contributed the code for scaling a vector Pony and filling it, replacing the bitmap Pony from the previous versions.

    COPYRIGHT
    Copyright (c) 2001, David Cantrell. The Artistic Licence applies.

    I don't think I need to mention that Leon Brocard works for Fotango [fotango.com], and that Fotango owns up [fotango.com] to adding their share of silly libraries to CPAN.

    And now they've gotten to Larry Wall himself.... :-)

    So, is there a URL for the State of the Onion talk this year then?

    • Good detective work! You're exactly right; the name was chosen (in part) to please London.pm.

      I'll try to get the State of the Onion talk up on Perl.com or the O'Reilly Network tomorrow.

  • Scheme (Score:2, Interesting)

    by Skeme ( 687563 )
    Last I heard, Dan Sugalowski said they planned to design Parrot so it could run Scheme code, as well as Python and Ruby, except it wouldn't be able to do continuations (which you need for Scheme). Anyone know more about this?

    Also Dan said that Parrot is more suitable for dynamically typed languages like those, while Mono and dot net are better for statically typed, like C# and Java. Anyone know more about that?

    • Re:Scheme (Score:4, Informative)

      by baka_boy ( 171146 ) <lennon@@@day-reynolds...com> on Wednesday July 09, 2003 @03:22AM (#6398741) Homepage
      Last I heard, Parrot was definitely intended to support continuations, as a low-level primitive for microthreading, generators, and coroutines. At least that's what Dan told me at LL1, and what the Parrot dev list summaries seem to keep indicating. That's not to say that all languages compiling to Parrot will use continuations, of course, but it will be there for those (Scheme, Ruby, and perhaps some day Smalltalk?) that do.

      Parrot is indeed designed to be a more dynamic runtime environment than Java, C#, etc., but that's really more of a compiler-level issue than a VM one -- i.e., compile-time type checking isn't something you implement at the VM level. And since Parrot supports a number of primitive types within the VM core, you could quite conceivably compile a low-level, C-like language to very efficient Parrot code.

    • Re:Scheme (Score:3, Interesting)

      by toomuchPerl ( 688058 )
      Parrot is more dynamically typed, yes, but they also made the wrong choice when choosing a VM. They wanted to support dynamic languages, so they should've chosen a Scheme VM and modified it from there. Consider that Scheme and Perl have very similar semantics in many cases, and that a modified Scheme VM could easily run Perl programs, matching the Perl semantic model.
      A system that combined some of the semantics of Lua with Scheme would actually be the most suited to this type of task. If you don't know wha

      • Re:Scheme (Score:3, Interesting)

        by Elian ( 10270 )
        Choosing a Scheme VM would've meant we'd have chosen a VM written for a language that nobody in the perl internals development community is fluent in, and use it to implement a language that most of the folks I know of in the Scheme community view with a (at best) barely disguised loathing. Rolling our own was the least bad of the options available.
        • It's not just for Perl though. Parrot is for everything, right? Scheme's going to be on it at some point, then. You can already match Python and Ruby's semantic model in Scheme, and AFAIK, most of Perl too if not all of it. It's therefore only sensible to look at it and think "Well, here is a solution".
          • Yeah, and the python and ruby folks don't do Scheme either. True, a Scheme interpreter is a solution, but for a variety of social, political, technical, and engineering reasons it's not a good solution for the problem. (Parrot isn't a great solution as a Scheme interpreter either, so it goes both ways, of course)

            • Re:Scheme (Score:2, Interesting)

              by toomuchPerl ( 688058 )
              What are these social, political, technical, and engineering reasons? Has this ever been discussed anywhere prior?

              Whether or not my perspective is wrong, my view is this:

              • Social and political reasons are really one and the same. Social reasons *are* political reasons, and vice versa.
              • The same ties in with technical and engineering problems.
              • What exactly do politics have to do with programming languages?
              • There are no engineering reasons to back down from anything, if everything you do is a kludge

              • What exactly do politics have to do with programming languages?

                One word: Ada [defenselink.mil].

                There are no engineering reasons to back down from anything

                If cost-benefit analysis indicates that a ground-up rewrite would provide better value than refactoring, even in the face of Joel's article [joelonsoftware.com], then what do you do?

        • The original Perl 6 development schedule from 2000:

          Forecast

          Design finished (end of 2001)
          Alpha released (Mayish 2002)
          Beta release (Julyish 2002)
          Perl 6.0.0 (Octoberish 2002)

          What stage are we at now?

    • Re:Scheme (Score:2, Interesting)

      by makapuf ( 412290 )
      this blog [sidhe.org] seems to be very interesting about how and why continuations, coroutines, closures, and the usual suspects (microthreads, ..) will be implemented in Parrot, by one of the main contributor of Parrot (he wrote the book about perl6)

      So ... RTFB

    • Re:Scheme (Score:4, Informative)

      by Elian ( 10270 ) on Wednesday July 09, 2003 @03:16PM (#6402704) Homepage
      Yup, we're doing continuations. We've actually switched to a full continuation-passing calling scheme, as it makes a number of things rather easier.

      We have, however, hidden that in most cases, so you generally don't need to fiddle with, or even care about, continuations if you don't want to. They're certainly not exposed by default at the language level so the python folks, for example, will never have to deal with them. (Nor will the perl or ruby folks if they don't want to) It's only if you're writing assembly directly, and even then it's pretty darned easy to not have to think about them.
    • Yes, because .NET does that. So we have to play catch-up.

  • Could anyone please explain why? (Score:3, Insightful)

    by Deagol ( 323173 ) on Wednesday July 09, 2003 @12:30PM (#6401357) Homepage
    Don't get me wrong -- I fell in love with perl ten years ago. I bought myself a handful of O'Reilly books that began my journey as a competant unix admin: Learning Sed and Awk, Learning Vi, and Learning Perl. Each book seemed to naturally lead to the other. While the first two have each had one update since then, the perl book had three (I think).

    I use sed, awk, vi, and perl the same way I did back then -- as the best damned text processing tools on the planet. Sed, awk, & perl haven't really changed at all.

    Sure, there's no reason that I can't continue to use perl the same way I always did. And I don't berate people for using perl's vast capabilities.

    But why does this once-elegant and simple tool continue to mutate and grow into the monstrosity it is? Why didn't Larry just start a totally new project? Why didn't perl (at around, say, version 4) just stop growing and simply go into maintenance mode (for example, adapting to larger capacity since memory and disk have grown by leaps and bounds since then)?

    I ask an honest question from soneone who's only sat on the fringes of programming. I used (and still use) perl only for basic text massaging. What need does the now-huge perl fill? Do these new-fangled languages like ruby and python fit the same need, just different approaches?

    • I think you can consider perl 6 to be a new project. I don't care about backwards compatability (as long as you can have dual installs of perl6 and perl5), but I care about cleaning up a lot of perl cruft.

      If it was an MS program, slashdorks would be complaining about MS adding unneeded crap. But not when it's poster boy perl.

    • From the peanut gallery for sure...

      I learned Perl in an amateur way in last year and half.

      Seems to me after you use it to glue all the cool stuff on a Linux box and web together with Perl, it is way, way beyond a text language. I know I wrote a wicked cool family history program in Perl. Seems like with all the modules, and the fact computers are so fast a scripting language is even quick enough for very nice 2-D graphics, there is more need for a language like Perl than ever before.

      I'd say from
      • As someone exposed to Perl and not really any other languages, there is one thing I dont get. There are all these complaints about Perl punctuation. Too my eyes, that punctuation makes it far EASIER to understand what a Perl Script is doing. That criticism really confuses me.
    • one reason... CPAN. The power that you bemoan, say gets in the way and you don't use a lot of *other* people use. You don't see it directly, you see it when you use modules that come from CPAN. Without the 'hacks' you talk about CPAN would not be possible. I personally find the functionality quite useful. Ed

Slashdot Top Deals

In the long run, every program becomes rococco, and then rubble. -- Alan Perlis

Close