Parrot 0.1.1 'Poicephalus' Released 224
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
preview for readability before submit, perhaps? (Score:3, Funny)
Holy run-on sentence, Batman!
Re:preview for readability before submit, perhaps? (Score:5, Insightful)
"New version of Parrot released".
It's reminiscent of badly written man pages, where a command has info like:
-n, --nfrtrt
enables use of nfrtrt.
And says no more. It's just a tiny addition, it would really help, and that's what we have editors for!
Re:preview for readability before submit, perhaps? (Score:2, Informative)
WE DON'T HAVE EDITORS (Score:2)
Readability? (Score:4, Funny)
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.
Hardly an improvement (Score:2)
My version [slashdot.org]:
Your version [slashdot.org]:
Re:Hardly an improvement (Score:2)
It is bereft of life. It is a dead parrot! (Score:2, Funny)
python performance (Score:2, Interesting)
Re:python performance (Score:5, Interesting)
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.
What do you mean (Score:2)
I realise there could be some applications where you want to sandbox embedded python - e.g. in webbrowsers, but surely not for most applications...
Re:python performance (Score:2)
Re:python performance (Score:2)
As for the article topic, I'm really enthusiastic abou
why? (Score:3, Interesting)
Re:why? (Score:5, Informative)
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
Re:why? (Score:3, Informative)
Re:why? (Score:2, Funny)
Oh, that explains it. Thanks.
Re:why? (Score:5, Informative)
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).
Re:why? (Score:3, Informative)
to hardware' is also rubbish.
For one, the type of the registers in parrot do
not map to the underlying hardware types (ints
and floats is all cpus can do), and second of all
not every CPU has all the registers parrot has.
So if you generate code that uses 32 registers,
you would still need to map to 6 registers on
Intel.
To make things worse, register allocation is
one of the hardest problems in a compiler, and
the one that probably has the most impact on the
performa
Re:why? (Score:2)
The meme of `register byte code will map nicely to harware' is also rubbish.
True, but the meme of 'stack machines are easier to tune because are conceptually simpler' is also a false.
The fact is that optimizing an VM is difficult, hell, after 50+ years of computer science we are stil trapped on a stack/register dicothomy!?.
Re:why? (Score:3, Informative)
but a linear representation of a tree.
It is in effect the output that you would get from
serializing a tree, so you turn internal compiler
representation, like for example the following
tree:
(assign var (add 1 2))
into a series of stack operations:
push 1
push 2
add
var_address
store
You can certainly "interpret" those bytecodes,
and for an interpreter it is debatable if there
is a performance improvement or not.
But for any self respecting JIT, the above is
only an MIR
Re:why? (Score:2)
Optimization is a complex issue, for instance, you can say, 'ok, in the end the program has to run on a given platform, so we can almost forget about intermediate representations, and focus our effort to create assemby code and then apply know platform optimizations'.
On the other side, you can say 'because we don't know apriori what the running platform is going to be, we better try to reformulate the program on his most optimistic expression, and only then proceeed to create assembly and re-optimize the c
Re:why? (Score:2)
to hardware' is also rubbish.
I don't believe this to be a true statement at all. It appears that they are using "typed registers", if you will. The optimizer is free to load ints and longs into registers while it can move pointers to strings into registers equally well. In other words, it maps VERY well to the underlying hardware.
Re:why? (Score:2)
Like Mathematica... (Score:3, Interesting)
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.
To ellaborate on the FAQ (Score:5, Informative)
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.
Re:why? (Score:5, Insightful)
- 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.
Re:why? (Score:3, Informative)
I'm no expert on all the political nuances, but there are at least two groups of people that can't use Unicode.
The first is a subset of CJK (Chinese, Japanese, and Korean) speakers. CJK support has been a political minefield for years, and Unicode just made it worse. If you're not aware, each of those languages uses Chinese ideograms in its written language (Korean less so today), even though the actual pronunciations are completely different. The first mine is the PRC's creation of "Simplified Chinese
Re:why? (Score:2)
Re:why? (Score:2)
I do, in fact, research my posts before I hit "Submit". I'm fully aware of just how big the Supplementary Multilingual Plane [unicode.org] is getting in the newest specs -- hell, the undeciphered Indus valley script [dkuug.dk] made it in there, albeit only as a preliminary proposal so far. However, there are still a handful of languages out there that aren't represented, including a few obscure but living languages (unfortunately I can't recall any of them, but we're talking <100 speakers left).
Re:why? (Score:2)
Re:why? (Score:2)
Awesome april fools joke (Score:4, Funny)
=====
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.
what is parrot? (Score:5, Informative)
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.
Re:what is parrot? (Score:4, Informative)
Moreover, libraries will (hopefully?) be possible to share code, especially libraries, across languages(!) so you could write your programs in ruby or python and still have access to all of CPAN, and vice versa. Talk about code reuse!
One of the big things I see a use for this, maybe to some extent already now, is scripting for game libs and engines. Those often have support for one or several languages, homebrewn or regular, in various stages of completion, with or without SWIG and it is all too often a huge big semi-maintained mess. With parrot bindings, you could use any supported language and possibly even mix - different languages are better at different things. Moreover, you could implement your own, custom languages to fit special tasks. Want a language that can handle 3d calcs, physics and AI interactions in a natural way? Just do it and reuse it for the whole series.
Ok, so maybe I am dreaming a bit, but having a powerful interpreter *made* for writing languages for, easily embedded, cross-platform and open source is something to really look forward to in so many ways! I just wish it'd hurry up getting there... and yes, I guess sometime I'll have to stop talking and start contributing myself.
And oh, there are already some simple games written using parrot and SDL, check em out. And do what I also should, join the effort!
Re:what is parrot? (Score:2)
Wouldn't that be "ternary", or am I mistaken?
Re:what is parrot? (Score:2)
Maybe he's a dolphin.
Explanations Please (Score:3, Insightful)
Mark Sparshatt is working on a Ruby project... (Score:5, Interesting)
He's done a few releases and appears to be making good progress here [rubyforge.org].
I was wondering... (Score:2)
I just started going through the joke links on the O'Reilly Parrot [oreilly.com] pages and started to wonder...
What happens to the joke pages when (if?) Parrot becomes mature enough to actually warrant a book?
Python support? (Score:5, Funny)
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.
Re:Python support? (Score:2)
mitzvah Audio pronunciation of "mitzvah" ( P ) Pronunciation Key (mtsv)
n. pl. mitzvoth (-vt, -vs) or mitzvahs
1.
1. A commandment of the Jewish law.
2. The fulfillment of such a commandment.
2. A worthy deed.
My vote is that he meant #2. Thanks to grandparent.
pasm rules (Score:3, Funny)
I spent far too long yesterday playing with parakeet, definately some interesting things happening in parrot land.
Another funny virtual machine (Score:4, Interesting)
A truly interesting project (Score:5, Interesting)
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.
Re:A truly interesting project (Score:2, Redundant)
You know, I never thought of that aspect of it. That is certainly exciting.
+1 Insightful!
Re:A truly interesting project (Score:2)
That could be a very nice descision indeed, and something for other libs (whether GUI, game, or whatever) to ponder also: when you are powered by parrot, you suddenly have a lot of potential languages to choose between for development, even your own(!) so you can use the ones most fit for any special task, and you
premature (Score:2)
Re:premature (Score:2)
Re: A truly interesting project (Score:2)
Not sure what you mean here -- I suspect you mean the gap between scripting languages and traditional ones.
If so, then I'd like to disagree :-) (And if not, please ignore the rest!)
While scripting languages have certainly closed the gap in terms of speed, and language features, there are more important considerations where they're still very far apart (and rightly so). I'm thinking particularly here of areas such as methodology
Re: A truly interesting project (Score:2)
You are indeed correct. They are very far apart, since "scripting" languages, whatever they may be, have already long surpassed "traditional" ones in (most of those) areas <g>.
Of course all the ranting on either side is of no use unless you define a "scripting language" is, since they're as muc
Re: A truly interesting project (Score:2)
I know lots of folks round here don't like it much, for various reasons (most of which I'd rather not get into yet more arguments about!). But it does seem to have been designed by people who 'get it', who understand what it's like not just to write little bits of code, but to write large systems, and to maintain them.
As we've said, you can't enforce good coding, but so many features of Jav
Re:A truly interesting project (Score:2)
I think that not being dependent on another language (including VM written in another language) is what discerns the scripting languages from the umm.. other ones.
So when the Parrot VM will be written in Perl (and compiled to Parrot bytecode by a Perl-to-Parrot compiler written in Perl and then presumably compiled by a Parrot-to-native compiler
Re:A truly interesting project (Score:3, Insightful)
And 4 years ago the Java people could happily say exactly the same thing about C#. If Parrot offers real advantages (and it does) then when it does arrive it is going to shake things up. Laugh now, but honestly, wait a few years and see if you're still laughing. I'll put rather good odds that if you are it will be very very nervous laughter.
Jedidiah.
Re:A truly interesting project (Score:2)
Re:A truly interesting project (Score:3, Interesting)
But the languages covered by Parrot have been around long before
--
Python VM? (Score:2)
Re:Python VM? (Score:2)
Re:Python VM? (Score:2)
I, for one, consider this a serious flaw that needs to be fixed before the language can be used for serious projects, as it presents a fundamental limit on scalability (adding additional processors will not make your
Re:Python VM? (Score:2)
The Python VM is a directy bytecode interpreter. It doesn't do JIT. Trying to retrofit JIT on a interpreter doesn't save you much work.
Holy Cow (Score:2, Funny)
A question (Score:3, Insightful)
Will Parrot, at some hypothetical point in the distant future, be able to decouple languages from libraries in the same way that
Re:A question (Score:2)
Re:A question (Score:4, Informative)
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.
Re:A question (Score:2)
So? That just means that they are not using Parrot. Big deal. What's you're point? You're point is that some people will use Parrot and others will use a different VM? I think we all, already understood this.
Re:A question (Score:2)
So much anger...so clueless...
The parent post was talking about a situation where other languages do run on Parrot but there's still an inte
Re:A question (Score:3, Interesting)
Potentially, you might even be able to switch and mix languages mid-file too, though that probably is not useful all that often.
Re:A question (Score:2)
Although, all those Inline::* [cpan.org] modules on CPAN is allowing you to do just that, so apparently people find it at the very least amusing.
Re:A question (Score:2)
Re:A question (Score:2, Interesting)
The answer, as far as i understand it, is YES! It's going to be bloody brilliant to be able to use the CPAN libraries from any language.
But it makes me wonder if
What is a "Poicephalus" (Score:3, Informative)
a brilliant project (Score:2, Interesting)
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 wou
Re:a brilliant project (Score:2, Informative)
It's not just possible, it's a goal.
Any existing language running on Parrot right now can use the SDL bindings, if the language has syntactic support for loading the appropriate library and calling class and instance methods.
As well, Tim Bunce's plans for DBI 2, Perl's almost ubiquitous database module family, includes porting it to Parrot to make it available to any language running on Parrot.
Everything compiles down to Parrot bytecode, so if your language has the syntax for interoperability, you'll
Uhm... (Score:2)
PHP support coming too (Score:2, Interesting)
b4n
Ah, but... (Score:2)
But does Parrot run Perl as of now?
What's The State Of INTERCAL Support (Score:2)
Re:Can I run .NET/CLR and JVM bytecode on it? (Score:2)
on a P4? CLR, JVM and Parrot are all different virtual *machines*.
Actually, you can (Score:2)
Re:Actually, you can (Score:2)
Right. It's my understanding that it's not a complete Java or
I'd like to see someone put complete support for Java and
Re:Can I run .NET/CLR and JVM bytecode on it? (Score:2)
Re:Can I run .NET/CLR and JVM bytecode on it? (Score:2, Funny)
mmm... JVM on Parrot on CPU goodness
Re:Can I run .NET/CLR and JVM bytecode on it? (Score:2)
Re:Can I run .NET/CLR and JVM bytecode on it? (Score:2)
Mind you, I was just being flippant when I posted the original
Parrot has a dotgnu OPS section (Score:2)
Volunteers needed :)
Re:Reconciliation (Score:2)
Most of the things that make people prefer Python to Perl have to do with the language itself, not the runtime.
To paraphrase a famous Simpsons quote: "My eyes...the runtime does nothing!"
Re:Reconciliation (Score:2)
Right... (Score:2)
Re:Right... (Score:2)
Parrot is a virtual machine which just happens to be able to run both of them.
Re:WTF is this? (Score:5, Informative)
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.
Re:WTF is this? (Score:3, Interesting)
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
Re:WTF is this? (Score:2)
Also, I suspect they are right that a VM targeted at dynamic languages will be more efficient for running those languages than one that was primarily designed for static languages, if only because the dynamic method dispatch code that a dynamic language on a static VM would have to emit for e
Re:WTF is this? (Score:5, Insightful)
Strong typing sucks.
Re:WTF is this? (Score:3)
Re:WTF is this? (Score:3, Interesting)
Certain types of programs really benefit from compile time type checking - specifically, those where inputs are known at compile time, or are kn
Re:WTF is this? (Score:3, Informative)
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 exampl
Re:WTF is this? (Score:5, Informative)
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:
Nothing inappropriate (Score:3, Interesting)
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 [wikipedia.org].
No reference counting (Score:2)
Unlike Perl 5 [perl.org] today, Parrot will not use reference counting. This is one of important difficulties which the Ponie [poniecode.org] project has to overcome. Please let me quote the most relevant parts of Parrot documentation [parrotcode.org].
Parrot FAQ [parrotcode.org]:
Re:Wow (Score:2)
It isn't hard to find (it should be linked from the main page, called 'The Incident with the Bird' or some such). I'm too lazy to link.