On Thu, 2004-07-22 at 19:21, JOSEPH RYAN wrote: > Well, that's what all of the ruckus is about. > There is a strong leaning towards including *no* > builtin modules with the core. So, that leaves only > the builtin functions and classes as "the core", and > so what is "in core" becomes a pretty big deal.
I don't think so. 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. Define "outside of the core", please. 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. 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 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. 4. The CPAN-like grab-bag of goodies. -- Aaron Sherman <[EMAIL PROTECTED]> Senior Systems Engineer and Perl Toolsmith http://www.ajs.com/~ajs/resume.html
