On Thu, Jul 30, 2009 at 8:17 PM, Timothy S. Nelson<[email protected]> wrote: > On Thu, 30 Jul 2009, James E Keenan wrote: > >> 1. Discussion of the benefits of adding any particular library to our >> "standard set" should also include any disadvantages or risks that that >> addition may pose. Potential downsides would include: More complexity in >> configuration? Slows down the executables? Bigger memory footprint? > > Hmm. Have we also considered Larry's reasons for including as little > as possible[*] in the Perl6 standard libraries? Not that I'm saying we have > to go with this, just that it might be a thought. > > [*] FSVO "little" and "possible" > > :) > > > --------------------------------------------------------------------- > | Name: Tim Nelson | Because the Creator is, | > | E-mail: [email protected] | I am | > --------------------------------------------------------------------- > > ----BEGIN GEEK CODE BLOCK---- > Version 3.12 > GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ > R(+) !tv b++ DI++++ D G+ e++>++++ h! y- > -----END GEEK CODE BLOCK----- > > _______________________________________________ > http://lists.parrot.org/mailman/listinfo/parrot-dev >
Obligatory mention that parrot NE Perl 6 ... ... but considering that point in the context of parrot itself is probably worth doing. Note that we're not talking about bundling the C libraries, just probing for them and having some wrapper PIR to invoke them; the footprint on that should be low. We also don't have a CPAN to fall back on; if we're going to want to provide things we don't ship core, we need a mechanism for users and distros to bundle them in if they want; having that will make the "in or out" decision for each library easier to make, I think. -- Will "Coke" Coleda _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
