Clemens,
"classpath"
I guess the proper term would be class library. The path is only where you look for the libraries :).
It doesn't seem to be the Perl way to limit yourself to one option only ("There's more than one way to do it").
I'd worry less about the Perl way to do it, since we're more concerned with the Parrot way to do it, and that's when we have one way that's good enough we ship it, so people don't have to re-invent the bikeshed, or choose from a half-dozen identically shaped but different colored sheds. Which means that we ship a core that's as small as feasable, and an add-on pack (which we'll likely also ship with the core for an all-in-one install) with the best things we can find that are cross-platform enough to be useful.
That means we'll shoot for a good set of networking modules for the various RFC protocols, a generic SQL database front-end, an (ick :) XML parser, a variety of cross-platform tools (filename conversions and whatnot), a set of xDBM interface modules, and some other stuff.
Don't forget there is an issue of us wanting to be a good core for more than just perl. The Python parrot package would have Python's standard module set, the Ruby package would have ruby's modules, and the Perl package would have the perl modules. There's a fair amount of overlap and I expect people both want their modules and *don't* want two or three alternate versions of the same modules installed. I could be wrong, of course.
GUI stuff's a massive pain, as you either get cross-platform which is ugly and awkward everywhere, or platform-specfic and useless anywhere but on the platform in question. And I'm pretty sure that, no matter *how* Insanely Great the OS X Cocoa interface modules are, they're not going to do MSWin folks much good. :)
As for sound... Yeesh. There's a swamp I don't have enough castles for.
However, since we have a good native interface it should mean that many modules that now require a compiler for can be done entirely in parrot bytecode, which should mean that it's far easier for people to install and reduce a lot of the pain. Also we've a fair amount of experience in the perl world with network module installation systems--we know some things that do work, and some things that don't, and I expect we should be able to leverage that to make a system better than what we have now. (Which, honestly, is pretty darned good, especially given the limited information it has available to work with)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
