[Python-Dev] Parrot -- should life imitate satire?

Dan Sugalski dan@sidhe.org
Sun, 12 Aug 2001 16:10:38 -0400 (EDT)

On Sun, 12 Aug 2001, Guido van Rossum wrote:

> > Perl 5.7.x has such a library, and it's my expectation (another sideways
> > glance at Dan) that if we did Parrot, it would include this library.
> > PerlIO attempts to be a very portable stdio (it's running on everything
> > that Perl runs on, AFAIK) and it supports "line disciplines" in the sfio
> > sense: you can stuff processing modules between the file and the
> > filehandle. This allows us to do anything between altering buffering
> > semantics, and decompressing and decrypting files on the fly.
> Great!

Two of the other design requirements are good async I/O support and
good event handling support. (So there's something to handle the completed
async I/Os) 

Rumors that we're just filing the serial numbers off the VMS I/O system
are, of course, wildly exaggerated. ;-)
> > It'll need to be somewhat rewritten for Perl 6, at which point I'm
> > hoping it'll be done in such a way that it'll make it easier to extract
> > from the Perl mess around it and be made available to other projects.
> I hope that even if the Parrot goal is to support all languages,
> PerlIO can be made a separate and independent project, not relying on
> Perl internals.  (And I'd change the name, but maybe that's asking too
> much. :-)

Nah, a name change would certainly be in order--we'd have to call it the
ParrotIO system. :) Making the core bits modular is one of the goals, for
no other reason than to make it easy to have someone responsible for its
maintenance and development that doesn't need to be intimately familiar
with the rest of the interpreter system. And so it'll still function
properly when we compile down to native code and don't actually *have* an
interpreter handy.

It ought to be an interesting project. Suggestions for features are, of
course, always welcome.