Parrot 0.0.7 Out (and some docs)

BorrisYeltsin writes "Big news in the Perl community this week is that Parrot 0.0.7 now out. New in this release is "Perl 6 grammar (with small, partial compiler), functional subroutine, coroutine and continuation PMCs, global variables, an intermediate code compiler (imcc), a pure-Perl assembler and working garbage collection." Also there are more Parrot docs! Check out the news here."

First "Non-First" Post!

[one9nine]

For those of you who were like me and have no clue what this story is talking about:

Parrot Code [parrotcode.org]
Parrot FAQ [parrotcode.org]
Parrot [britannica.com]

Can't seem to download new Parrot..

[XaXXon]

All the links seem to be down, and the code doesn't appear to be in CPAN -- at least not in the right place. If anyone can find a working link, please post it as a reply to this. Thank you.

Parrot a cross between Perl and Python

[Bouncings]

Wasn't parrot an April fools joke [oreilly.com] of a cross between Perl and Python? Well, where's the mention of Python (either on slashdot or the perl news they link to?). It looks like just a fancy Perl compiler -- nothing to do with Python.

Can someone fill me in?

Re:Parrot a cross between Perl and Python

[LunaticLeo]

Yes Parrot was a April fools joke [slashdot.org].

However, then it was chosen as the name for the Perl6 Virtual Machine. The name Parrot was chosen because the programmers envisoned that the VM, which is designed for dynamic languages, could be used by both Python and Ruby. And Parrot was the name of a fictional project to do just that, hence make the fiction into reality. Nice joke on a joke.

BTW, people keep asking "Why make Yet Another VM?". The answer is that this "Virtual Machine" is a high level VM. For instance, something like regular expression operations might be a single assembly op in this VM. Or dispatching a method on an object might be a single op. Parrot is not a Virtual CPU, it is a synthesis of the highest level of operations that can be distilled from several dynamic languages.

From the little I have seen on the perl6-internals mailing list, Parrot looks like it will be faster and smaller than the current Perl5 runtime. Further, It looks like the Ruby folk are more interested in cooperating than the Python folk. But in my mind it would be amazing if Python, Perl6, Ruby, and some Lisp variations all had Parrot backends.

Re:Parrot a cross between Perl and Python

[IamTheRealMike]

Further, It looks like the Ruby folk are more interested in cooperating than the Python folk. But in my mind it would be amazing if Python, Perl6, Ruby, and some Lisp variations all had Parrot backends.

I was just researching Parrot when I came across this story. The problem with Python isn't so much that they're not interested, it's more lack of volunteers. All the "core team" (only about 4/5 people) is too busy maintaining the language. Python should be fairly easy to retarget to Parrot though.

I do think this would be cool. We need a truly open cross-language VM. Mono would be OK, but unfortunately there are just way too many people (including me) who just don't trust Microsoft with .NET

What especially interests me is the possibility that Parrot binaries could share objects and such - this would for the first time allow Perl to use Python code and vice-versa (as well as any other languages targetted to Parrot). The merge between Python and Perl was an April Fools joke, but I'm wondering - would it not make sense to allow code to be easily shared between them and to construct a .NET style "shared" set of APIs? The amount of code duplication is staggering with these two languages, if it could be cut down that'd be fantastic.

Re:Parrot a cross between Perl and Python

[LunaticLeo]

We need a truly open cross-language VM. Mono would be OK,

According to stuff I saw on perl6-internals, both the Mono and Java Virtual Machines would be to low-level for Parrot. Both of those VMs are pretty close to the metal. My read of this is that MVM and JVM are really largely virtual CPUs. Where Parrot is a simplification of Perl op codes and generalization to allow other dynamic languages target their op-code generation to Parrot assembly (aka op-codes).

From what I gather, sharing parrot-compiled libraries accros languages is a stated goal of Parrot.

Re:Parrot a cross between Perl and Python

[XaXXon]

The problem with other virtual machines written for other languages is that they are optimized for static binding, strict type-checking languages, which Perl, Python, and Ruby are not. That's where parrot comes in. Someone else mentioned that in Parrot, a regular expression is a single assembly instruction in Parrot. Java doesn't even have regular expressions built into the language.

Re:Parrot a cross between Perl and Python

[IamTheRealMike]

So could parrot also be used by a lower-level, strictly typed language? Would it be possible to target C++ for it for instance?

Re:Parrot a cross between Perl and Python

[babbage]

That's my hope. From what I've heard -- Boston.pm meetings where Dan Sugalski, Parrot developer gaves talks on the project -- it's very hard to get a dynamic language like Perl, Python, Ruby, or Lisp to run on the static-oriented virtual machines like JVM, CLI, and Mono. On the other hand, getting the static languages to run on top of the dynamic runtime engine might not be that bad -- they just won't be leveraging the cool high level hooks put in there for the Perls etc.

If so, then the point isn't "we don't need Parrot since we've already got Mono/JVM/CLI, etc", it's that "we're getting Parrot so we won't need Mono/JVM/CLI". Parrot gets the upper hand there. Programs written for say Microsoft's .NET CLI -- Office 2004 anyone? -- could hypothetically work on any machine that has an instance of Parrot installed. Hey presto, all that Win32ware just got ported to Linux/BSD/BeOS/etc... :)

'course, this is all strictly hypothetical at this point, and I personally don't know nearly enough about the field to contribute much, but I'd love to see it happen within the next few years...

Visual C++ .NET supports "managed" C++ on .NET

[cpeterso]

Visual C++ .NET 2002 (aka MSVC7) supports "managed" C++ for the .NET CLR. That is, C++ code can be compiled down to MSIL byte bytes, be garbage-collected (!!), and interact with .NET libraries. Sounds like a good transition strategy for legacy C++ code..

Visual C++ .NET Managed Extensions for C++ [microsoft.com]

Inevitable

[ejdmoo]

Polly want an update?