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!
Actually, all jokes aside it looks like a valiant try.
I am especially interested in python support. I love python but it is some times a tad bit slow. I've seen lots of interesting initiatives to really improve performance (the starkiller python to C++ "compiler" for example), and am now very curious to see how good this one will perform. Besides, it would be quite funny to have perl and python united :-)
Why a new VM? Jython showed it is possible to "recycle" the java VM. Can anybody explain why this is better?
10 ?"Hello World" life was simple then
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.
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.
...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.
well, seeing as the .Net CLR and JVMs are currently built on top of a register based architecture (namely a CPU), theres no reason why someone (preferably not likely to miss their sanity) could port mono or an OSS JVM to run on top of parrot.
mmm... JVM on Parrot on CPU goodness
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 told my perl buddies how perl could affect the readability of their day to day life language usage. Now we have this post as example :)
And no, it's apparently not a FA one.
.NET does? This is IMO the most exciting thing about .NET - once new languages are no longer guillotined in their infancy by the "but there aren't any libraries for it!" hurdle, a veritable renaissance in language design becomes possible, and maybe we can finally crawl out of the backward-compatibility tarpit.
Will Parrot, at some hypothetical point in the distant future, be able to decouple languages from libraries in the same way that
"The Genus Poicephalus are small to medium sized, stocky birds with short, squarish tails and proportionately substantial bills." I guess it's just your basic African parrot, then. Funny, with the word "phalus" in it, I thought it would be something else...
"Freedom means freedom for everybody" -- Dick Cheney
Strong typing sucks.
In the course of every project, it will become necessary to shoot the scientists and begin production.
"Honey, it's not working out; I think we should make our relationship open-source."
With so many open source language implementations around these days, developing a VM that any of them can take advantage of is a fantastic idea.
One focussed effort on providing efficient JIT compilation will improve performance, and similarly this one layer to address portability could do more to break down OS barriers than java managed.
I'm excited about Parrot just for that, but if there is any possibility that different languages will be able to make use of libraries written in others, then that would be the icing on the cake. I can't tell if it should be possible, but if I could make use of someone else's library written in their favourite languge, from my favourite languge (by virtue of them both running on Parrot), software would be a whole lot more fun.
Really.
Parrot's runtime sounds a whole lot like what Mathematica does internally: dynamically typed language which compiles JIT into a bytecode for a register-windowing VM.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
This is really a performance issue, not a type safety issue. If type safety is particularly important, then type checks can be done at run time. However, doing these type checks at run time has a run time performance cost. Doing these same checks at compile time means that compiled code will run that much faster since no type checks are being performed at run time.
Certain types of programs really benefit from compile time type checking - specifically, those where inputs are known at compile time, or are known to be of certain types, or are known to be safe (i.e., inputs are not coming at your program across the wire from a potentiall hostile source - think any web app that takes free form input from users).
It could be argued that in the modern GUI/networked era, many apps are going to be doing lots of run time checking anyway because they are exposed to data inputs from potentially hostile users on a WAN - i.e., the internet, and they are at the mercy of user GUI inputs (bizarre mouse clicks and drags, bogus text or numeric field entries, etc.). That being the case, being able to do type inference and compile time type checks doesn't buy one much in terms of saftey or performance for any such app, since you'll be doing lots of run time type checks on user input data anyway.
IMHO, the idea of compile time type inference and type checking is born of a model of computing that is becoming obsolete. It was how most computation was done just a few decades ago - the programmer controlled the input closely, and so could guarantee inputs of certain types in certain ranges, etc. We have now moved into an era where the most interesting inputs are essentially unknowable at compile time - these are user inputs, whether GUI, keyboard, or network in origin. Just as importantly, user choice destroys the notion of a fixed algorithm executing in a predicable fasion. We simply can't know what direction our programs will take once we allow the user sufficient choice in shaping the programs execution. This being the case, and increasingly so as we go forward, I think that compile time type checking is a backward looking paradigm for programming languages.
See Peter Wegner's home page for some related ideas on new ways of thinking about what it is that a program really does in the modern interactive GUI/network era.
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."
There is nothing inappropriate in poicephalus as e.g. poicephalus gulielmi is just a Latin name of Red-fronted Parrot, well known for every bird lover, just like agapornis pullarius is a Latin name of Red-headed Lovebird, another proposed code-name for this release. You are probably thinking about phallus for some reason but instead of looking for Freudian connotations you might want to read more about parrots.
Sincerely,
Pan Tarhei Hosé, PhD.
"Homo sum et cogito ergo odi profanum vulgus et libido."
Sterling Hughes and Thies Arntzen are working on getting PHP to parrot with their project Pint. They want some stuff in PHP and parrot would fit perfectly, but havin access to modules from perl or pythong is a nice extra bonus.
b4n
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:
A few comments: .NET did exist when Parrot was announced, and more .NET into an ECMA .NET is designed for compiled languages as much
.NET provides a lot of
.NET can execute dynamic Python code as fast or
importantly the work to turn
standard had started way before this.
as the x86 is designed for compiled languages
(in fact the x86 is strongly typed and knows about
two types: ints and floats, nothing else).
So anyways, for those who can see further than
the end of their noses,
sugar for strongly typed OO languages, but it
requires a strong effort to be as naive to think
that dynamic languages are not supported.
In any case, IronPython has demostrated that
faster than the Python interpreter itself.
So those two stated reasons for Parrot are rubbish.
On the other hand, its perfectly fine to say
`We wanted to do something different' or `we
wanted to do our own thing'. Nothing wrong with
that.
Miguel.
I would be very interested to see an example of a real-world application where unpredictable user inputs can demonstrably render static type-checking useless, or where static type-checking makes a real-world application significantly harder to write. Because I sure can't think of one.
Static type checking is still useful for those portions of the program that are, well, static. Any part of the program that deals only with data that is known at compile time, can benefit from static type checking. For example, if your menus are not dynamic (their content does not change) then that portion of your code can benefit from static type checking, etc.
But by far the more difficult bit is dealing with data that isn't known at compile time. Let's take the same example. What if I have a menu item that lists the names of recently opened files with their full path - say in a File menu. However, the menu drawing code I use assumes that all menu items are less than a certain number of characters. There is absolutely no way that I as a programmer can know at compile time whether the type of that file path will be stringLessThan64Characters, or whatever the limit is. I must do a run time check of the data, and respond accordingly. The benefits of compile time type checking are lost for this portion of the code, because it is interactive. The nature of the data that my algorithms will be dealing with cannot be known at compile time because it is determined by user input.
This issue is multiplied in the sequences of user mouse and keyboard actions in, for example, a graphics program. The user can cut/paste/drag/drop/copy-drag etc. At each juncture, my code must check the nature of the data to assure that it can be handled by my algorithms. Static type checking here becomes of little utility. I end up with much of my data being of type "Untyped" and so, it must be type checked repeatedly at run time.
Note that this need to do run time type checking is unavoidable not only in practice but in principle. There is simply no way to know what the type of the data generated by a complex series of user actions will be. Remember that type in this sense is strict, and includes such things as data size and dimensions, not just the underlying primitive type of which it is made. It is not enough to know that I'm getting a slew of bytes, I must know that they are well formed wrt my application's algorithms, and that they are of the right range of size.
Now add to this multiple user interactions across the network, and realize that by far your most important task with regard to type checking is not the ivory tower theoretical exercise of type inference, but the very real world task of checking each and every piece of data that the users throw at your code, and the results of combinations of such user inputs that you may not have originally predicted ("Oh, it never occurred to me that the user would select that menu item, click this radio button, type in such -and-such and then click this other unrelated button").
The more interactive a piece of software is, the more choices the user has, the greater the use of network connectivity, the more the need for run time type checking. Since I'm doing all of these run time type checks, not because I want to, but because I have to I might as well use a language that is designed on the basis of run time type checking. I simply define the necessary constrained types I need, and throw an execption/condition when one of my functions/methods is called with the wrong type, as determined at run time.
The future belongs to interactive software, and interactive software demands run time type checking. It follows that the future belongs to languages that are dynamically typed.