Parrot "standard libraries"

[Allison Randal]

Geoffrey Broadwell wrote:
>     2. Use libraries provided by other HLLs.
> 
> Ever since the major HLLs were split from Parrot, option 2 has become
> weaker, in the sense that no HLL can *count* on another HLL being
> available.  Thus HLL and HLL module implementers are more likely to
> reimplement than tell their users "Want to use my spiffy new Cardinal
> module?  First install Rakudo and these Rakudo modules ...."

Some libraries can be precompiled to PBC and shipped as Parrot modules 
that way. This is substantially preferable to reimplementing the whole 
library.

 > The following are some tests that I would use to help make
 > the decision:

I mostly agree with your criteria, but you missed a big one: The 
long-term investment of developer resources in *maintaining* the modules 
once we include them.

The module set shipped in Parrot core should be small, with extensions 
shipped separately. Parrot is not a language like Python, Ruby, etc. 
It's a compiler toolchain like GCC.

> 1. True core
> 
> Just what is needed to get read access to the module repo.  Parrot
> release management owns these (they are considered part of Parrot in
> every sense, including deprecation cycles), and they should be truly a
> minimal set.

Agreed except for the "module repo" part. There are so many free ways of 
distributing software these days (SourceForge, GitHub, Google Code, 
Debian, Cygwin, Active State, etc), there's very little value in 
creating a CPAN-like module repository.

Having Parrot modules in every major code repository works for us, far 
more than being silo'd into a dedicated Parrot module repo. It's all 
about visibility, and increasing the chances of a random person 
stumbling across module X that solves their problem, and just happens to 
require Parrot.

> 2. Basic batteries
> 
> The stuff everyone has hashed to death, agree on, and (like DBDI) form a
> common layer through which other things are easy to plug in.  The Parrot
> and HLL teams work together to decide what goes into this set, with a
> general preference for less rather than more.  We may want to have a
> separate "basic batteries release manager" who takes care of making
> these releases (perhaps on the same day as Parrot Core, perhaps a day or
> two later), thus taking stress and politics off the Parrot Core release
> manager.

Aside from DBDI, I'm not sure what would go here, and even DBDI should 
likely have more independence than this would allow.

> 3. Power packs
> 
> What we currently think are the most common modules people would want
> for a particular market segment.  For example, there could be a "Power
> Pack for Scientists" and a "Power Pack for Hackers".  Anyone should be
> able to create and manage power packs, and it is expected that the
> market place of ideas will do its magic -- for example, someone may
> decide to make a "Power Pack for Bioinformatics" that has more focus and
> depth than the general scientific pack.  These are explicitly NOT
> managed by the Parrot team; we merely support the tools necessary to
> make them easy to install.  I personally think we should try to create a
> culture among the power pack owners to deprecate and clean regularly,
> but as pmichaud pointed out, there is likely a market for power packs
> (especially in the business spaces) that make stability and long-term
> support the primary goal.

This idea I really like. And it's not just individual developers likely 
to create these bundles, we can expect commercial bundles too. Also 
virtual packages in distributions, to bundle up a group of module packages.

And, don't forget that language implementations are really just modules 
too. So, we'll likely see the Rakudo Pack, Python Pack, etc.

> 4. Go use the module repo
> 
> If you need anything not in a power pack, just use the module repo
> directly; the tools to use it are after all part of Parrot Core.

All modules should be installable from source, using some simple, common 
build/installation framework (make, autoconf, etc...), but we're not 
going to dictate one that everyone has to use. For now I suspect most 
modules will copy Parrot's makefile generation technique, since we 
provide some tools to make that relatively easy.

If a developer expects their module to be commonly used, it should be 
packaged for our major target distributions and operating systems (we 
can provide tools for that too).

Allison