Besides serving as what is hoped to be an appropriate and effective platform for Perl 6 and other languages, Parrot is a grand experiment. Is there a better way to write a compiler than using the lex and yacc model? Can languages interoperate at a deeper level than sharing a set of calling conventions? Here are some answers.
Like the best April Fool’s jokes, Parrot took on a life of its own.
Simon Cozens, the editor of Perl.com, published a joint interview with Perl designer Larry Wall and Python designer Guido van Rossum announcing that both languages were to merge into a single language named “Parrot” (http://www.perl.com/pub/2001/04/01/parrot.htm). As Perl 6 was under heavy design at the time, it seemed obvious to Larry (or so said the interview) that merging with Python was appropriate. Within a week, Simon owned up to the hoax (http://www.oreillynet.com/pub/a/oreilly/news/parrotstory_0401.html).
Somehow, though, the idea stuck. Perhaps merging two languages with different philosophies and designs is a bad idea, but allowing them to interoperate on a single virtual machine — to use Perl libraries from Python, and vice versa, in the same program — might have tremendous benefits. Besides, Perl 6 needed a new virtual machine (VM) anyway, as the internals of Perl 5 were aging and it wasn’t clear that the code could cleanly or easily support the new features of Perl 6. Thus, work actually began on Parrot, a virtual machine designed to allow dynamic languages to interoperate.
Features of the Design
The short list of useful languages includes Python, Ruby, Lua, Tcl, PHP, Scheme, and JavaScript/ECMAScript. A dream list might include older languages, such as PL/1, Perl 1, and Smalltalk. Parrot’s original architect, Dan Sugalski, even ported an aging 4GL compiler to Parrot to provide a better platform for a client.
With a VM that supports all of those…
Please log in to view this content.
Not Yet a Member?
Register with LinuxMagazine.com and get free access to the entire archive, including:
