Tom Christiansen wrote:
>
> >So ripping all this 'cruft' would save us about 100-160 kB, still
> >leaving us with well over a 1MB-plus executable. It's Perl itself
> >that's big, not the thin glue to the system functions.
>
> Moreover, if you rip out that 100-160 kb, allocating it to modules,
> then I can guarantee you that it will cost significantly more memory
> as a module to pull in that if it here already there. There's always
> some overhead involved in these things. Notice how the Byteloader
> produces much bigger executables than the originals. Some work has
> been done to fix that, but as a minimum, you've got the Byteloader
> module itself. And it gets worse...
Depends on your definition of "module". Many people seem to be assuming
"module" eq "shared library". I submit that a better definition would be
anything that uses the Perl6 Core API.
The vision I have is that all existing builtins _could_ be linked with
the "perl core". The new builtins (a small list) always will be -- they
require inside knowledge of data structures that should specifically not
be exposed to extensions. (With a "please", not a shotgun.) Any or all
of the "core modules" could be placed into one or separate shared
libraries. They would have no more access to the internals than any 3rd
party module. (That's my real definition of a module -- it's a property
of the architecture, not of the linkage, preprocessing, author, or
whatever else.)
What this means is that we have to define a recommended API for modules
to use (and warn that compatibility is not assured if they dig deeper
than this), and to make sure that sin(), socket() etc. strictly obey
this discipline. If this API is too raw for the convenience of many
extensions, then we can always layer it with a kindler gentler API, but
the bottom-most API should be the important one. At compile time, you
can choose which things you want linked into the perl core, which ones
to stick in a shared library, and which ones to leave out entirely, with
a warning "what you are about to compile is not Perl" if they choose to
leave out any "core module" entirely. In fact, the binary should then be
called "phbbbbt" rather than "perl".
Whether this is implemented via the preprocessor, autogenerated code, or
? is a separate issue. It seems easily possible to define an API that
allows either static or dynamic linking with no performance loss.
Maybe this is what some people are already assuming. I just thought I
should spell it out. It's probably implied by the RFC that says user
subs should be indistinguishable from opcodes (doesn't one that sound
something like that exist? I'm too lazy to go look.)
