Parrot "standard libraries"

[Allison Randal]

Patrick R. Michaud wrote:
> Allison Randal wrote:
>> 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.

For embedded environments, we need a way to bundle up a compiled HLL 
module so it doesn't depend on the entire parser and runtime environment 
of the HLL. Including some part of the HLL runtime is workable, but it 
needs to be the smallest set possible. Disabling some features like eval 
for embedded use is fine. The same is true for a generic portable 
compiled library.

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

Sensible.

Allison