Ponie: Perl On New Internal Engine

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."

Comments

Pony??? I blame London.pm

[babbage]

The proof is in the CPAN:

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, and that Fotango owns up 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?

Re:Scheme

[baka_boy]

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

[toomuchPerl]

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 what Lua is, well, it has hooks that allow you to specify events which occur when certain things happen. Like, when a hash table is accessed, you can overload that behavior (which Perl has with TIE), or when an undefined subroutine might be called, you can override that behavior. (which Perl has with AUTOLOAD). Lua 5 just got coroutines, lexical closures, and tail calls - sounds an *awful* lot like Scheme, no? :)
-toomuchPerl

Re:$perl %syntax @sucks

[ichimunki]

Um. There are scads of Perl web development books written by people who DO NOT know what they're doing. And thousands more actual web developers working in Perl who don't know what they're doing as a result. I know. I used to be one of them. Language wars are a waste of time. The original post was probably off-topic, since this is not a general "criticize Perl" thread. Indeed, the sigil change issue has been answered for Perl 6. The sigils will no longer change. However, there are many of us who find the character indicates type characteristic of Perl to be distracting. In a truly OO language, this can only lead to pain and suffering. If Perl OO is to be more than a hack, the sigils have got to go.

In any case, the concerns about context are completely baseless. So what? It's not like context is subjective in Perl. It's just a factor to deal with when programming. It makes the code more expressive with less effort. That's one of the stated goals of Perl: laziness. In this case, it's a great idea. Not one that is perfectly implemented in Perl, necessarily, but nonetheless a fantastic notion.

Re:Scheme

[Elian]

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.