Do any C++ programmers consider the STL to be anything other than "in core" even though it's not part of the compiler, and with at least GCC, it's distributed as a separate component?
Do any C programmers consider strlen or sprintf to be outside of the core? It's part of the ANSI C *STANDARD LIBRARY*, not the ANSI C spec.
Does anyone really ship compilers w/o a standard library. I don't care if they are in separate tar/rpm/etc files. As long as they go together. Does anyone other than a spec writer document the language minus the library?
Define "outside of the core", please.
I'm sticking to my definition involving the camel book and packing them together.
If I was going to make a recommendation (which I guess I am), I would suggest having 4 layers of library:
1. Really-really core (the stuff you can't write the other stuff without), and is probably all built-ins in Parrot.
The toy for the researcher. Not much of a tool yet, but fun.
2. Really core. This is the sort of "standard library". Just the most essential bits that are required for general Perl usability. You'd probably include most of these, even in a "trimmed down" release, such as an OS installer
What most venders will ship.
3. The "extended core". The modules from some CPAN-alike that are considered to be "supported Perl extensions" In Perl 5, I think of libwww-perl and libnet this way, but making an official distinction lets users decide what modules to rely on in code that will have to be "updatable" for 5 years.
What my site IT people might get around to installing in the site image for perl 6 during the perl 8.2 time frame.
4. The CPAN-like grab-bag of goodies.
The pre-pre-alpha modules that work on two-ish platforms. Many of which were in the same state a year ago.
OK, maybe I'm over stating that. But I do think that if perl 6.X.Y is not accompanied by a packaged perl library version I.J.K that is as documented, tested and portable as the language, then most people won't see any modules outside of those shipped in the perl6 source archive. I hate that.
To put it another, if a library version is not done in concert with a given language version, then either users can't rely on the availability or exact behavior of any function beyond the core package. Each vendor with have to make their own library, and test it.
Overlooking the duplication of effort for each vender, given that vendors seem to have enough trouble packaging remotely recent versions of perl 5, and given that different venders might not choose the same selection of modules or that they might not pick compatible versions of the same modules, this just looks like a black eye waiting to happen. This all assumes that venders put the effort into it at all.
If not the venders, do you expect each perl programmer to have root -like access? I could have missed the chapter, but I didn't see a good way for a perl programmer to install from CPAN to his home directory and use it seemlessly with an OS shipped perl install. So far my experience do it with CPAN haven't gone well anyone. Maybe each user could compile his own interpreter from source. That's how I had my best luck. I still get lots of errors on CPAN installs. It's kind of a pain. Besides, things should be run out of a user's home directory in a production environment.
I know this isn't a new problem, but it is why I didn't use Net::FTP at work until about a year ago. They just didn't install the bugger and I didn't have control of the site image. The same goes for perl5.6 for that matter, so I might not see perl6 at work before I retire in some 20 years from now and this will all be moot.
I just think there ought to be a decent library. It worked well for python and java (even inspite of how java's library is designed!) and it would put perl ahead of the likes of C and C++ (which I believe have far too skinny standard libraries to be useful).
I also think that library needs to be tested as well as perl6. It needs to be equally portable as well. (Yes I know there are limits there. If TK won't run on my watch, I'll understand. I'm sure the watch probably won't support all the core features either.)
And a given version of the library needs to 'go together' with a given version of the language. The gcc folks may not tar the C++ standard lib up with the compiler, but there tends to be a given version of one to use with a given version of the other.
Of course, maybe there are other solutions. Maybe I'm wrong for thinking it ought to be a requirement. Maybe I just need to work at a shop with more perl biggots on staff.
Dan
