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
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
