[Python-Dev] Parrot -- should life imitate satire?
Eric S. Raymond
Mon, 30 Jul 2001 01:48:59 -0400
The 2001 O'Reilly Open Source Convention, was, as usual, a very stimulating
event and a forum for a lot of valuable high-level conversations between
the principal developers of many open-source projects.
Many of you know that I maintain friendly and relatively close
relations with a number of senior Perl hackers, including both Larry
Wall himself and others like Chip Salzenberg, Randall Schwartz, Tom
Christiansen, Adam Turoff, and more recently Simon Cozens (who lurks on
this list these days). At OSCon I believe I got a pretty good picture
of what the leaders of the Perl community are thinking and planning
these days. They have definitely come out of the slump they were in a
year ago -- there's a much-renewed sense of energy over there.
I think their plans offer both the Perl and Python communities some
large strategic opportunities. Specifically, I'm urging the Python
community's leadership to seriously explore the possibility of helping
make the Parrot hoax into a working reality. I have discussed this
with Guido by phone, and though he is skeptical about such an
implementation being actually possible, he also thinks the idea has
tremendous potential and says he is willing to support it in public.
The Perl people have blocked out an architecture for Perl 6 that
envisages a new bytecode level, designed and implemented from
scratch. They're very serious about this; I participated in some
discussions of the bytecode design (and, incidentally, argued that
the bytecode should emulate a stack rather than a register machine
because the cost/speed disparities that justify register architectures
in hardware don't exist in a software VM).
The Perl people are receptive -- indeed, some of them are actively pushing --
the idea that their new bytecode should not be Perl-specific. Dan Sugalski,
the current lead for the bytecode interpreter project, has named it Parrot.
At the Perl 6 talk I attended, Chip Salzenberg speculated in public about
possibly supporting a common runtime for Perl, Python, Ruby, and Intercal(!).
One of the things that makes this an unprecedented opportunity is that
the design of Perl 6 is not yet set in stone -- and Larry has already
shown a willingness to move it in a Pythonward direction. Syntactically,
Perl 5's -> syntax is going away to be replaced by a Python-like dot
with implicit dereferencing (and Larry said in public this was
Python's influence, not Java's). The languages have of course converged
in other ways recently -- Python's new lexical scoping actually brings
it closer to Perl "use strict" semantics.
I believe the way is open for Python's leading technical people to be
involved as co-equals in the design and implementation of the Parrot
bytecode interpreter. I have even detected some willingness to use
Python's existing bytecode as a design model for Parrot, and perhaps
even portions of the Python interpreter codebase!
One bold but possibly workable proposal would be to offer Dan and the
Parrot project the Python bytecode interpreter as a base for the Parrot
code, and then be willing to incorporate whatever (probably relatively
minor) extensions are needed to support Perl 6's primitives.
Following my conversation with Guido, I've put doing an architectural
comparison of the existing Python and Perl bytecodes at the top of my
priority list. I'm flying to Taipei tomorrow and will have a lot of
hours on airplanes with my laptop to do this.
Committing a common runtime with Perl would mean relinquishing
exclusive design control of our bytecode level, but the Perl people
seem themselves willing to give up *their* exclusive control to make
this work. It is rather remarkable how respectful of Python they have
become, and I can't emphasize enough that I think they are truly ready
for us to come to the project as equal partners.
(One important place where I think everybody understands the Python
side of the force would clearly win out in a final Parrot design is in
the extension-and-embedding facilities. Perl XS is acknowledged to be
a nasty mess. My guess is the Perl guys would drop it like a hot rock
for our stuff -- that would be as clear a win for them as co-opting
Perl-style regexps was for us.)
I think the benefits of a successful unification at the bytecode
level, together with Larry's willingness to Pythonify the upper level
of Perl 6 a bit, could be vast -- both for the Python community in
particular and for scripting-language users in general.
1. Mixed-language programming in Perl and Python could become almost
seamless, with all that implies for both languages getting the use of
each others' libraries.
2. The prospects for getting decent Python compilation to native code would
improve if both the Python and Perl communities were strongly motivated
to solve the bytecode-compilation problem.
3. More generally, the fact remains that Perl's user/developer base is
still much larger than ours. Successful unification would co-opt a
lot of that energy for Python. Because the brain drain between Perl
and Python is pretty much unidirectional in Python's favor (a fact
even the top Perl hackers ruefully acknowledge), I don't think we need
worry about being subsumed in that larger community either.
I think there is a wonderful opportunity here for the Python and Perl
developers to lead the open-source world. If we can do a good Parrot
design together, I think it will be hard for the smaller scripting
language communities to resist its pull. Ultimately, the common
Parrot runtime could become the open-source community's answer -- a
very competititive answer -- to the common runtime Microsoft is
pushing for .NET.
I think trying to make Parrot work would be worth some serious effort.
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
The Bible is not my book, and Christianity is not my religion. I could never
give assent to the long, complicated statements of Christian dogma.
-- Abraham Lincoln