Parrot "standard libraries"

[Patrick R. Michaud]

On Thu, Aug 06, 2009 at 08:53:15PM -0700, Allison Randal wrote:
> 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.

This does not seem entirely accurate (or complete), as it makes it
sound as though a HLL library can be compiled to a PBC and then
run from Parrot even when the HLL is not installed as well.  In the 
general case this is likely to be false, since most HLL libraries 
will need to make use of HLL-specific library functions, methods, 
and dynamic PMC types that are typically available only by having the 
entire compiler present.  Thus Geoffrey's statement above is essentially 
correct that if a Cardinal module depends on a Rakudo module, then both
the Cardinal and Rakudo runtimes will need to be present in order to 
be able to use it (whether or not it has been precompiled to a .pbc).

And for dynamic languages that support eval() or other dynamic
compilation (e.g. dynamic regexes), the entire compiler is essentially 
part of the runtime.

> > 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.

I'll note that Rakudo itself will be taking a "core versus distribution"
philosophy, whereby a very small compiler core will be maintained
separately from distributions.  We'll expect most users to download
a distribution (with various integrated modules and the like), while 
the compiler core will consist primarily of only the builtin methods
with few additional modules.  The compiler core will also keep its
own release cycle independent of distribution releases.

Pm