Parrot 1.0.0 Released 120
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."
Re:Down too?! (Score:4, Informative)
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 [wikipedia.org]
Enjoy!
Re:Down too?! (Score:4, Informative)
try this:
http://lwn.net/Articles/324196/ [lwn.net]
1.0 is for a stable API (Score:4, Informative)
Re:VM question (Score:5, Informative)
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 (Score:3, Informative)
Re:Is it really ready? (Score:5, Informative)
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.
The original Parrot was an April Fool's joke (Score:5, Informative)
It included a mock press release: Perl and Python Announce Joint Development [perl.org].
And a joint "interview" of Larry and Guido [perl.com].
O'Reilly Media even tossed in a bogus book announcement: Programming Parrot in a Nutshell [oreilly.com].
A few days later, O'Reilly published The Story Behind the Parrot Prank [oreilly.com].
The name was eventually adopted by this project.
Re:VM question (Score:3, Informative)
Parrot is at a higher level than LLVM. Parrot deals with things like multiple dispatch, garbage collection, closures, and more at the virtual machine level. LLVM is meant to be an efficient way to target a real machine in the back end of a compiler that supports optimization and JIT.
Parrot could actually target LLVM as a backend. There have actually been tests showing that Parrot compiles under llvm-gcc. Something has to be the front end for any compiler or virtual machine, and Parrot is that. The back end will need to be tweaked for different targets anyway, and LLVM may well be one of those.
Re:VM question (Score:2, Informative)
Also, .NET 4.0 is supposed to ship with the Dynamic Language Runtime (DLR): http://en.wikipedia.org/wiki/Dynamic_Language_Runtime [wikipedia.org]
Re:VM question (Score:4, Informative)
"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:Perl 6 before end of century? (Score:2, Informative)
Re:I can't believe it! (Score:3, Informative)
Re:Lord of the Bytecodes (Score:2, Informative)
Re:VM question (Score:3, Informative)
Personally, I believe they are all doing it wrong, and all in the same way. They all assume things about the programming languages that will target the VM, and build the VM to support the constructs they've assumed the language will use.
I am much more in favor of a language-agostic approach. In my own TurboVM [sourceforge.net], I have instead chosen to implement a simple, RISC-like instruction set, reasoning that this would allow the same techniques that are used to implement existing languages on real hardware to be used to implement languages on TurboVM. No need to work around the fact that you get objects and methods, garbage collection, dynamic typing, etc. when you don't want them - TurboVM gives what a real machine would give you, without any bias towards specific programming languages.
Re:From the Release Announcement (Score:1, Informative)
She's one courageous lady and I think the song is a decent tribute.
Each to his own though.
Re:Compiler for Perl? (Score:3, Informative)
http://search.cpan.org/~nwclark/perl-5.8.9/ext/B/B/Bytecode.pm [cpan.org]:
NOTICE
There are also undocumented bugs and options.
THIS CODE IS HIGHLY EXPERIMENTAL. USE AT YOUR OWN RISK.
AUTHORS
Originally written by Malcolm Beattie and modified by Benjamin Stuhl .
Rewritten by Enache Adrian , 2003 a.d.
B::Bytecode is an experimental feature that's been largly abandoned since 2003. Perl5 is too much of a mess to make a bytecode compiler work. That's why Parrot exists.
Re:I can't believe it! (Score:3, Informative)
That's because register-based interpreters are faster than stack-based interpreters. Generally speaking, the fewer instructions you run in a bytecode interpreter, the faster it will execute. That is the argument made in the paper posted by mj41 above.
When you throw a JIT into the mix, things change rapidly. You stop being concerned about the interpreter speed and begin worrying more about machine code optimizations. What's good for the goose may be good for the gander, but what's good for the interpreter is not always good for the JIT.
Interestingly, there is only one Javascript JIT in wide distribution at the moment. That is Chrome's V8. Tamarin is also used in Flash 9 & 10 and is expected in future versions of Firefox.
Unfortunately, JITs are much more resource intensive to develop and maintain than interpreters. Thus a small company like Opera isn't going to make a JIT their first priority. A fast interpreter makes a lot more sense from their perspective. Especially when the Javascript engine spends the vast majority of its time in native APIs.
Re:Lord of the Bytecodes (Score:3, Informative)
ASCII character 42 (decimal) is '*'. ASCII character 0x42 (hex) is 'B'. Sorry, try again.