Parrot "standard libraries"
Will Coleda
will at coleda.com
Fri Jul 31 00:21:15 UTC 2009
On Thu, Jul 30, 2009 at 8:17 PM, Timothy S. Nelson<wayland at wayland.id.au> 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 wayland.id.au | 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
More information about the parrot-dev
mailing list