Parrot 0.1.1 'Poicephalus' Released

Pan T. Hose writes "The long awaited release of Parrot 0.1.1 "Poicephalus" has been finally announced on perl.perl6.internals newsgroup and perl6-internals mailing list simultaneously by Leopold Toetsch followed by an announcement on use Perl by Will Coleda and now also on Slashdot." (Read on for a list of changes since the last release, as well as a number of useful links.) Pan T. Hose continues "The most important changes since the previous version 0.1.0 (code-named 'Leaping Kakapo' and released in February) are:

• Python support: Parrot runs 4/7 of the pie-thon test suite
• Better OS support: more platforms, compilers, OS functions
• Improved PIR syntax for method calls and <op>= assignment
• Dynamic loading reworked including a "make install" target
• MMD - multi method dispatch for binary vtable methods
• Library improvement and cleanup
• BigInt, Complex, *Array, Slice, Enumerate, None PMC classes
• IA64 and hppa JIT support
• Tons of fixes, improvements, new tests, and documentation updates

The amazing project which no one had any idea would go so far from the original April Fool's Joke by Simon Cozens (also posted on Slashdot on April 1, 2001) to really unite Perl and Python one day (not to mention Tcl, Scheme, Forth and Ruby, to name just a few) is now available for download from CPAN and via CVS. Those who are not up-to-date with Perl 6 mailing lists can read This Week in Perl 6 weekly summaries by Piers Cawley to have some idea on how's the project been going in the last two years. It's important to read Apocalypses, Exegeses and Synopses together with RFCs and Parrot Design Documents for better understanding of the underlying rationale, especially the superiority of register-based Virtual Machines (like Parrot VM) over stack-based one (like JVM) for modern (dynamically-typed) OO languages with multiple inheritance, operator overloading, traits, roles and much, much more. Parrot Docs, FAQ and examples are also very helpful. This is a very important step in the direction of Perl 6 which we are all looking forward to."

Comments

what is parrot?

[egott]

from the faq:

Parrot is the new interpreter being designed from scratch to support the upcoming Perl6 language. It is being designed as a standalone virtual machine that can be used to execute bytecode compiled dynamic languages such as Perl6, but also Perl5. Ideally, Parrot can be used to support other dynamic, bytecode-compiled languages such as Python, Ruby and Tcl.

Re:why?

[BridgeBum]

Performance.

From the FAQ:

Why your own virtual machine? Why not compile to JVM/.NET?
Those VMs are designed for statically typed languages. That's fine, since Java, C#, and lots of other languages are statically typed. Perl isn't. For a variety of reasons, it means that Perl would run more slowly there than on an interpreter geared towards dynamic languages.

The .NET VM didn't even exist when we started development, or at least we didn't know about it when we were working on the design. We do now, though it's still not suitable.

So you won't run on JVM/.NET?
Sure we will. They're just not our first target. We build our own interpreter/VM, then when that's working we start in on the JVM and/or .NET back ends.

Re:WTF is this?

[Bob of Dole]

That's not what it is. Perl and Python (and most "major" interpreted languages, I would suspect), first compile the script to byte-code, then execute the byte-code in a VM.

At some point along the line, someone said "Hey! Why are we writting VMs for every single language? They all do pretty much the same thing!".

So Parrot is that, a common VM. Perl6 compiles to Parrot bytecode, instead of the perl-only-bytecode it was using for Perl5.
Since that bytecode format is open, and the VM free, any other interpreted (or compiled, I guess) language (Python, Ruby, TCL, LUA, whatever) can make their compilers output Parrot bytecode.
That way they don't have to build and maintain their own VM, and they get the benefits of future optimizations to Parrot.

For example, I could write a just-in-time compiler for Parrot for my favorite platform, and every Parrot-enabled language could take advantage of that.
Doing that now, I'd have to pick a language to optimize. Do I want to make Python faster? Or Perl?

Python is going to use it in the future,last I heard. (probably as another backend like Jython or IronPython, not as a replacement for CPython)
I think they were waiting on the byte-code format stabilizing.

All in all, it's a very cool idea. Makes it a hell of a lot easier for people to make new interpreted languages, since they only have to target Parrot, and they've got a mature, debugged, VM that runs on multiple platforms. (in theory, at least. I don't think it's there yet)

It's not that similar to the JavaVM (which is only designed to run Java, not a pile of different languages), but it is kinda like the .Net VM.
The developers of Parrot created Parrot instead of targeting .Net for two reasons:
1. .Net didn't exist when they began :)
2. .Net is designed for compiled languages (C++, C#, VB, etc), and supposedly that would cause a performance hit over a VM designed for interpreted languages. (Plus, it's not designed to be portable, like Parrot is)

Re:WTF is this?

[eidechse]

Strong typing sucks.

This is NOT a strong vs weak typing thing. This is a static vs dynamic typing thing. The strength of a type system has no relation to when it's enforced.

You can have all combinations:

• strong/static (e.g. Java)
• strong/dynamic (e.g. Python)
• weak/static (e.g. C)
• weak/dynamic (e.g. Perl)