Sorry this is so long. No time to condense it.
On Tue, Sep 19, 2000 at 07:41:20PM -0000, Perl6 RFC Librarian wrote:
>
> =head2 Core bloat?
>
> The most obvious objection is core bloat. 5.6.0 is already over 5
> megs and only going to get fatter. Throwing lots of modules into the
> core will only make it even bigger, possibly getting up to 10 megs!
> There are a few solutions for this.
>
> The first is to provide several distributions of Perl. A minimalistic
> distribution might provide just perl and a handful of modules.
On the face of it, this sounds good as an *alternative* distribution.
I imagine some sites want to get only the core language, and none
of the modules unless they are explicitly required.
> Another provides the docs.
Eh, don't know about this one. This is one of the "bugs" Python has
with their distribution system.
Are you proposing something like this:
Standard distribution:
1: Everything (core, docs, standard modules)
Alternative Distribution:
2a: core language (+ pragmatic modules)
2b: standard modules
2c: docs (possibly split into tutorials and reference)
Or some other mechanism?
That would avoid the buggy Python distribution problem. The 2a..2c
dists should all untar into the same directory, producing the same
set of files that the dist #1 produces.
It shouldn't matter if 2a..2c is further subdivided, so long as it's
a "small" number of files to download.
> Another is to provide several different install options. "make
> install" installs everything, as usual. "make small_install" installs
> just the current set of modules. "make tiny_install" installs a bare
> minimum, not even docs.
How much of the problem is the size of the install vs. the size of
the download?
> Finally, we've got about 18 months before Perl 6 is expected to ship.
> In that time, DSL and cable modems will become more and more
> ubiquitous (my B<dad> has one!) and pulling down 10 megs will be less
> of an issue for Joe Average. Users still on low bandwidth can get one
> of the slimmer distributions.
While this is a concern, I think this is a lesser concern thatn building
a version of perl out-of-the-box that makes more sense for embedded
uses of Perl (e.g. Perl within Mozilla, PalmPerl).
> =head1 IMPLEMENTATION
>
> The integration and upkeep of existing CPAN modules is already a
> fairly well-understood procedure. The only foreseeable problem is
> configuring and testing those modules requiring network access, as
> this is not always available.
Er, how about:
=head1 IMPLEMENTATION
A permanent ad-hoc working group should be created to discuss the
perl6 standard library as the project comes closer to shipping code.
The charter should include selection criteria for adding modules
into the core distribution, as well as design criteria for
modules that aim to be included into the core (e.g. adhering
to perlstyle).
> =head1 REFERENCES
>
> RFC 228 - Add memoize into the standard library
Add a section on memoize to the list of modules to add, and I'll retract
RFC 228.
Z.
