Parrot 1.0.0 Released

outZider writes "Parrot 1.0.0 was released last night! The release of Parrot 1.0 provides the first "stable" release to developers, with a supportable, stable API for language developers to build from. For those who don't know, Parrot is a virtual machine for dynamic languages like Perl, PHP, Python, and Ruby, and is best known as the virtual machine for Rakudo, the reference implementation of Perl 6."

Comments

Lord of the Bytecodes

[Anonymous Coward]

One Bytecode to rule them all, One Bytecode to describe them, One Bytecode to bring them all and in the OS bind them.

Slashdotted parrot

[davidwr]

I'll tell you what's wrong with it, my lad. 'E's slashdotted, that's what's wrong with it!

Re:Slashdotted parrot

[Yvan256]

Not it's not! It's just swapping!

Re:Slashdotted parrot

[QRDeNameland]

It's pining for the DWORDs!

Re:Down too?!

[Volanin]

This is the first time I heard about Parrot, and it really got my attention as well.
I know it's common knowlegde, but you can get more information in wikipedia:

http://en.wikipedia.org/wiki/Parrot_virtual_machine

Enjoy!

Re:Down too?!

[Randle_Revar]

try this:
http://lwn.net/Articles/324196/

1.0 is for a stable API

[tcsh(1)]

Remember that their plans for the 1.0 release was for a stable API for language implementors, not highly optimized performance.

Re:Perl 6 reference implementation

[outZider]

Surprisingly. The idea is to do a full language specification, so there can be many implementations of a language, similar to how Java (theoretically) works. This is also why there is an absolutely huge, yet incomplete, test suite. More tests are passing weekly, but more tests are being generated weekly.

VM question

[benjfowler]

Question from somebody who's done some compiler work with VMs but not Parrot...

What does Parrot do that other VMs can't (e.g. the .NET dynamic language runtime on the CLR, or the JVM?)

Without knowing better, it seems like a lot of duplicated effort to me...

Re:VM question

[outZider]

I'm not very good with thedetailed explanation, as I am not a Parrot developer, but Parrot's VM is geared toward dynamically typed languages like Perl, Python, Ruby, and PHP. The JVM and CLR are geared toward static typed languages, which is why dynamic language ports to the CLR generally require code changes and cleanup to work properly under those environments.

Parrot gives all the benefits of a virtual machine to the dynamic side of the language aisle, while being incredibly easy to extend and build on, and is open source from the start.

Re:VM question

[bernh]

Note that .NET and JVM have been built with a focus on static languages like C# and Java. As far as I know Parrot is a register based virtual machine and should be especially suited for _dynamic_ languages like Perl, Python, Ruby, ... Time will tell if the theoretic advantages here will result in a better real-world performance as the other VMs.

Re:VM question

[mj41]

chromatic said on reddit.com:

"It's not so much that the CLR's limitations prevent it from running dynamic languages but that the CLR's limitations require you to invent a lot of your own infrastructure to run dynamic languages. If the CLR in itself assumes that it can resolve all method dispatches (or jump targets or attribute accesses) statically at compile time, you have to invent your own dynamicity atop that. If the CLR does not support first class functions, you have to invent your own approach. If the CLR does not support first-class continuations, you have to invent your own calling structure. Ditto named parameters, optional parameters, default parameters, and whatever other features that the CLR doesn't support.

I'm not saying that the CLR doesn't support all of those features -- I know that it does support some of them, to some degree. The DLR supports more. The question is whether Turing equivalence (and I hate this argument) is sufficient, or whether you're better off not inventing your own method dispatch system."

Re:Is it really ready?

[hardburn]

Version 1 is supposed to be reasonably complete and provide a consistent API for language developers.

Version 2 is intended to be the production-ready version. According to the roadmap laid out last Dec., that's due to come in another year. So far, they've stuck to the roadmap pretty well.

Re:Compiler for Perl?

[drinkypoo]

Slightly off topic: Is there a compiler for Perl, that is not based on bytecode, and therefore is difficult to decompile?

I thought perl source was considered sufficiently obfuscated that it was safe from reverse-engineering in source form. Why on Earth would you want to do something like this anyway?

Re:Compiler for Perl?

[hardburn]

Perl 5 isn't really bytecode at all. It basically just walks the parse tree directly.

Perl 6/Parrot is bytecode just as those from Python or Java have come to expect. Perl 5 could be reimplemented this way, but nobody seems to want to bother.

If your goal is to obfuscate your code to prevent people from copying it, please give up.

The original Parrot was an April Fool's joke

[ptbarnett]

The original Slashdot article from almost 8 years ago: Perl + Python = Parrot.

It included a mock press release: Perl and Python Announce Joint Development.

And a joint "interview" of Larry and Guido.

O'Reilly Media even tossed in a bogus book announcement: Programming Parrot in a Nutshell.

A few days later, O'Reilly published The Story Behind the Parrot Prank.

The name was eventually adopted by this project.

Re:I can't believe it!

[mr_mischief]

Considering the JVM is a stack machine VM for statically typed languages, .NET is a stack machine VM for statically-typed languages, and Parrot is a register machine VM built for dynamically-typed languages perhaps it's not so "me too".

Re:I can't believe it!

[mj41]

The Case for Virtual Register Machines, Brian Davis, Andrew Beatty, Kevin Casey, David Gregg and John Waldron, 12.6.2003, PDF

Re:Compiler for Perl?

[Onymous Coward]

Perl is very difficult to read if you don't know Perl, by which I mean all of Perl.

Rather...

Perl is very difficult to read if you don't know Perl, by which I mean as much of Perl as the guy who wrote the program used.

But, yeah, I'm with you. The basic idea is that you can't read Perl if you're not literate. At least to the degree of the author of the work you're reading. So, basically, anyone who says Perl is hard to read is a bystander.

Perl can be hard to read if you don't know it. But it can be wonderfully concise if you do. That concision is valuable, so I'll take that. Even if it means having to learn the language first.

Re:Compiler for Perl?

[Phroggy]

If you don't know the language, what are you doing maintaining Perl code? I consider that professionally irresponsible, at least if you're getting paid.

Oh, absolutely, no question there. I was thinking of people messing around for fun, not getting paid to maintain Perl code in a professional environment.

(Where do you look up the /g flag for the JavaScript example?)

When you look up the String.replace method, it should explain /g there. In my Perl example, you have to recognize that ~ is actually part of the =~ operator, and that s is part of the s/// operator; once you know what these are, you can look them up in perlop (and indeed, /g is explained there).

Obviously this isn't a realistic example; any Perl beginner should know the syntax I used. My point was that because other languages rely more heavily on functions to accomplish things that Perl has a unique syntax for (which makes Perl easier and more fun to write), other languages are easier to read because when you come to a function you're not familiar with you can easily look it up. With Perl, if you don't recognize the syntax, you don't know what to look up, so you're stuck (or you misinterpret what's going on).