I've an idea to cut down and weed out the huge number of RFCs we have.
Its written out below.
=pod
=head1 TITLE
Prototype implementations for RFCs.
=head1 VERSION
Maintainer: Michael G Schwern <[EMAIL PROTECTED]>
Date: Mon Sep 4 21:11:56 EDT 2000
Version: 1
Mailing List: [EMAIL PROTECTED]
=head1 ABSTRACT
RFCs should be followed by a prototype implementation of their
proposal which provides something concrete to develop the RFC from and
helps to avoid endless discussion.
=head1 DESCRIPTION
Its very easy and quick to write an RFC. Its often quite a bit harder
to actually do what is proposed. There is also a tendency for endless
discussions to come from them.
In order to avoid the inertia inherent in the Perl development
process, to discourage RFCs which have not been well thought out, and
to cut down on the sheer number, it is proposed that each RFC should
eventually be accompanyed by a prototype implementation before any
decision to include it in Perl 6.
Work on such an implementation will rapidly weed out those who wish to
work on the proposal and those who wish to simply talk about it. If a
person has strong feelings about an RFC or a particular feature of an
RFC, their energies can be directed at working on the prototype rather
replying to emails about the RFC. One who's opinion is backed up by a
well implemented patch will carry more weight than one who merely
proposes something without code. In effect, it restores the
meritocracy of open source development.
The prototype will allow people to actually work with the proposal,
coding with and around it in a practical setting. Many things will be
revealed during this process, and many issues which were never thought
about will come up.
It also allows documentation and testing cases to be drawn up
B<before> any code is added to Perl 6.
In some cases, the prototype may work out so well that a core patch is
not necessary. The prototype would become the implementation,
possibly released to CPAN and/or distrubuted with Perl.
It is, of course, expected that prototypes may be slower, less
portable and more buggy than their eventual complete implementation.
It is, after all, a prototype. It doesn't have to be perfect or
complete, but it does have to give it a good try.
Many existing RFCs are very deficient in their discussion of its
implementation. The most common reasons given are either "This should
be trivial" or "I an not a Perl core hacker".
For the former case, if the implementation is so trivial, the
prototype should also be trivial. If that turns out not to be the
case, then maybe the RFC wasn't as trivial as originally thought.
Provides a good check.
In latter case, if the RFC author does not have the necessary time,
manpower, brainpower, etc... to implement the RFC then it is their
responsibility to find someone who does. This also holds true for the
prototype. If the RFC author feels they cannot implement the
prototype on their own, they must find people who can. If they can't,
then they're not going to be able to find those to implement the
actual code either.
=head2 Weeding out dead RFCs.
An RFC which goes for a period without a prototype, or without any
patches to its existing prototype, will be considered "dead in the
water." After sending out warnings to the maintainer to get things
moving and giving a grace period, the RFC will be moved out of the
main RFC archive and into an attic.
One the RFC begins motion again, the maintainer can ask to have it
reinstanted into the archive.
Two special cases exist. An RFC for which no prototype can be written
(RFC 16, for example) and an RFC which considers its prototype to be
complete. A complete prototype must not only be feature complete, but
it must also contain complete documentation and a complete testing
suite.
=head1 IMPLEMENTATION
Prototypes can be written as modules, wrapper scripts around Perl 5,
Filter.pm modules, Perl5 core patches, etc... Not every RFC can have
a prototype, nor can every feature be implemented, but this is the
exception rather than the rule.
This will require the Perl 6 code repository to be set up eariler than
expected.
The RFC archive will have to be expanded to include a link-up between
the RFC and its latest prototype. It will also require the RFC
librarian to weed out RFCs which have languished for long periods with
no prototype.
The RFC maintainer will also be the build maintainer of their
particular prototype. They ultimately decide which patches go into
the main branch of the code. Rival implementations may be maintained
as branches by their chief supporter.
=head1 EXAMPLES
Some examples of RFCs which can have prototypes and that which are exempt.
=over 4
=item RFC 1 - Implementation of Threads in Perl
This RFC's scope is so wide as to necessitate a complete rewrite of
Perl. It would be exempt from a prototype.
=item RFC 5 - Multiline Comments for Perl
This can be prototyped using a source filter.
=item RFC 7 - Higher resolution time values
This can be prototyped based on the existing Time::HiRes module
=item RFC 193 - Objects: Core support for method delegation
A prototype already exists, Class::Delegation
=back
=head1 REFERENCES
L<Filter>, L<perlfilter> and L<Semi::SemiColons> (as an example of a
simple source filter)
Damian Conway has done some amazing modifications to the language
using plain Perl. L<Switch>, L<Class::Delegation>, L<Class::Contract>
and L<Lingua::Romana::Perligata> are excellent examples of how far
this can go.
=cut
--
Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED]
Just Another Stupid Consultant Perl6 Kwalitee Ashuranse
BOFH excuse #232:
Ionisation from the air-conditioning
