Parrot "standard libraries"

Will Coleda will at
Fri Jul 31 00:21:15 UTC 2009

On Thu, Jul 30, 2009 at 8:17 PM, Timothy S. Nelson<wayland at> 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: wayland at    | I am                           |
> ---------------------------------------------------------------------
> 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-
> _______________________________________________

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

More information about the parrot-dev mailing list