Slashdot Mirror
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
Holy run-on sentence, Batman!
For those too lazy to click on the april fools links, the programming examples were some of the funnies things I've seen.
=====
Show us some Parrot code.
GvR: [...]
# copy stdin to stdout, except for lines starting with #
while left_angle_right_angle:
if dollar_underscore[0] =eq= "#":
continue_next;
}
print dollar_underscore;
}
[...]There's more than one way to do it, right, [...]
LW: [...]
while(@line = Sys::Stdin->readline()):
continue_next if $line[0] =eq= "#":
print @line;
}
============
From the minute I saw that I thought I'd love the language. Truely shows the power of open source.
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.
There are 10 kinds of people: Those that understand ternary; those that don't; and those that don't care.
Performance.
.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.
.NET back ends.
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
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
My UID is the product of 2 primes.
When posting software projects (especially those whose version number 0) please add a quicky bit about the package for the lazy amongs us
My posts are definitive. Reality is frequently inaccurate.
The problem is that Python's slowness isn't just from the interpreter, but the nature of the language. Notice how two similar objects don't require an interface to be used in the same way with the same methods? Because of that it will be hard to store members as anything but dictionaries, which are necessarily slow.
Either way Parrot will be an improvement, allowing shared Python/Perl/Ruby libraries, importing pure-python modules nicely, and most importantly: maybe we can finally sandbox Python. Rexec has been dead a long time, and Python is currently unusable as an embedding language without a lot of hacking because of that.
...that would compile Ruby programs into intermediate compiler code so they could be run on Parrot.
He's done a few releases and appears to be making good progress here.
The Army reading list
Ouch!
Now I'll get my thumb out of my ass and pass along my gratitude to everybody who's worked on Parrot. An open-source VM, particularly one targeted at existing open-source languages, is a mitzvah. It even has the nice side benefit of creating a little commonality between the communities. Thank you.
WWJD for a Klondike Bar?
Parrot assembler is the nicest asm dialect I've ever had the pleasure to work with. I'm looking forward to a new mod_parrot so I can do enterprise web apps, the way they should be done; in asm.
I spent far too long yesterday playing with parakeet, definately some interesting things happening in parrot land.
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.
.Net VM. .Net for two reasons: .Net didn't exist when they began :) .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)
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
The developers of Parrot created Parrot instead of targeting
1.
2.
I respond to your sigs
The Virtual Virtual Machine is, if I understand correctly, a virtual machine to build virtual machines.
-- Did you try Tao3D? http://tao3d.sourceforge.net
Parrot is a very interesting project indeed, and it looks as if it is now starting to seriously pick up steam. What we're looking at here is VM that works, and is optimised for Perl, Python, Ruby, Forth and all those other lovely scripting languages.
.NET and Java vs. C# people seemed to have missed Parrot creeping up from behind. Potentially Parrot can pull together Perl, Python and Ruby - imagine CPAN that works with all of those languages at once, but pulls in all the interesting Python and Ruby libraries too.
.NET via Mono or Java via JVM shoudl start considering Perl/Python/Ruby via Parrot as a very serious choice for doing the high level application programming.
Given all the current debate raging over JVM vs.
In general scripting languages have been looked down upon, but realistically the gap between scripting languages (and what you even mean by "scripting language") has been drastically narrowed to the point where it is increasingly less relevant. The only serious remaining issue is speed - and that's something Parrot can help fix, putting Perl, Python and Ruby code on a similar footing as Java and C# code running on their VMs. You'll take a small hit for using a higher level language, but it won't be as drastic as it is now.
Maybe all that GNOME discussion about
Jedidiah.
Craft Beer Programming T-shirts
As it said, Python, Perl, Ruby, Smalltalk, Lisp, and most of the languages targeted by Parrot are dynamically typed and have dynamic message passing (method calls). This means that typechecking is done by the run-time environment, not by the compiler. Likewise, it is not known untill runtime which if an object has a method. Therefore, the runtime has to do a fair amount of checking (mostly symbol table lookups). If you were to do this with a VM designed for static languages (JVM, .NET) that do not do this checking for you, then you would have to implement all of it as byte-code in the VM - in effect you would be writing a big chunk of a Perl interpretor in Java.
This approach would inevitably be slower than the existing Perl 5 interpretor, while the Parrot approach has managed to be significatly faster than the current Perl 5 interpretor. The reasons are that 1) all of the runtime checking is highly optimized native code 2) after the complex perl code is translated into a simpler form, the traditional compiler optimizations can be applied to the code.
I think he means register based.
From one of the examples, we get:
set I1, 1
set N1, 4.2
set S1, "Resting"
print I1
print ", "
print N1
print ", "
print S1
print "\n"
end
Which seems to indicate a heavy use of register type functionality. This will map to hardware (thusly faster) better, much more so than a stack based (java) VM implementation. Especially for dynamically typed languages (perl, python, ruby, etc).
- Language neutrality
- Support for very high level language inter-operation (e.g. you can sub-class a Python object in Perl and call a method on the Perl class that gets invoked fromt he Python class).
- Deep support for multiple character sets, not just ASCII and Unicode.
- Perl 6
The last item might seem odd, but Perl 6 is definitely a language which needed some serious support. It's very ambitious, and a VM that didn't support its needs as completely as Parrot does would have exponentially complicated writing a compiler for it.That said, the combination of the two promises to be one of the most powerful development platforms released to date.
Strong typing sucks.
In the course of every project, it will become necessary to shoot the scientists and begin production.
That's funny you mention it because quite frankly I did preview it and in fact it was not until then when I decided to turn a list of comma separated values into a bullet list as well as brake the second then single-sentence paragraph into three separate sentences exactly because I was somewhat concerned readability-wise--though to be fair braking it into two parts and adding "Read on for a list of changes since the last release, as well as a number of useful links" we owe to Timothy, who has also removed quite a few important links for some reason--but nevertheless I am quite surprised if not outright disappointed that anyone who is even remotely interested in Perl 6 might lack basic linguistic skills to parse a paragraph of simple English, however on the other hand I can understand that for some people interested in the subject my story might indeed contain not nearly enough whitespace.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
The point of that is also that you have only one debugged runtime and don't have to write your own for each language.
A very important fact hasn't been mentioned here: When you compile multiple languages to the same VM, you don't automatically get interoperatibility between those languages. Interoperatibility is a different concept that must be separately achieved, mostly by defining additional rules and standards on-top-of the VM specification.
For example, look at different C or C++ compilers on Linux/x86. They all compile to the same machine code, but Intel machine code has no concept of "symbol names", "class names", "type names" etc., so, for the compiled codes to be interoperable, they must comply to additional specifications like ELF or some C++ ABI ("name mangling").
Parrot bytecode may define some or all of those concepts, but some scripting languages will probably define additional features (macros, MI, continuations etc.) that have no "native" representation in Parrot, so additional conventions to represent those things in Parrot must be agreed upon. The .NET CLS ("common language specification") is another example of such a set of addional rules to provide for language interoperatibility.
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: