|Version 1 (modified by Austin_Hastings, 4 years ago)|
The Parrot VM Glossy Brochure
"If I have seen a little further it is by standing on the shoulders of Giants."
-- Isaac Newton
In Why Parrot Is Important, Allison Randal points out that an ex nihilo programming language project will face man-years of effort just to catch up to where the state of the art was when the project kicked off.
But it turns out that support for dynamic languages pretty much means support for static languages, too. So people are building Pascal and a C variant on Parrot, too.
How does that affect me?
If you're strictly a language user, it means that in a few years you'll have a Parrot VM on every computer you own.
But if you're implementing a language, or a compiler, or a subset of a compiler -- like a pretty printer or syntax checker or "lint" utility -- you need to be aware of Parrot for the simple reason that Parrot does the first 90% of the work for you. All you need to provide is the second 90%.
... standing on the shoulders of Giants
The best kind of problem is one that someone has already solved for you. Parrot is a giant toolbox full of solutions.
Parser, Syntax Tree, ... done?
Allison talks in her article about the Parrot Compiler Toolkit (PCT). What she doesn't point out is the different between working with PCT and working with other parser generators:
flex+bison: We'll generate a lexer and parser. You need to provide action routines and data structures after that.
ANTLR: We'll generate a combined parser/lexer that converts source code into an AST (Abstract Syntax Tree). After that, there are some tools you can use to help reshape the tree.
Parrot PCT: We'll generate a combined parser/lexer that converts source code into an AST. Once you've got the AST the way you want it, you're done, because we've already got the tools to convert from AST to an OST down to Parrot byte code.
For most of the 90's and the early part of this decade there were two ways to process arbitrary Unicode data. The first way was to write a perl script. The second way was to write a Java program, then realize that you didn't have your encodings right, and then wrap your java code in a perl script.
Given that Parrot aims to support Perl6, support for Unicode is automatically available. In fact, not supporting Unicode might be more of a challenge.
It turns out that the mod_perl6 Apache module is actually built on top of the mod_parrot Apache module. And not surprisingly, any language built on Parrot can hook into Apache with < 100 lines of code.
Want to generate your dynamic Thai web pages out of a database from interpreted object-oriented Cobol? You bring the Cobol grammar, Parrot will bring the rest.
Standing on the shoulders of Pygmies
Some of these features are "big ticket" items. But maybe you just want to do a really, really good job of handling dates in your business logic. What then?
Well, if a module runs on Parrot, in any language, you can call it.
This actually kind of puts the problem back on you. Maybe you've got a list of places you look for cool source code. (Perl's CPAN? PHP's PEAR?) Now there might be a solution waiting for you in any of a dozen languages. If you're going to have a problem, this is a good problem to have.