|Note: these documents may be out of date. Do not use as reference!|
To see what is currently happening visit http://www.perl6.org/
Larry Wall will decide the changes to make for perl6 based on our suggestions. To make life easy for him, we should put some effort into our suggestions. RFCs are intended to be focus discussion on something that will be useful to Larry when he makes his decisions.
This format was last changed July 31, 2000.
RFCs are written in POD. rfc-sample.pod is a sample. The important sections are: TITLE, VERSION, ABSTRACT, DESCRIPTION, IMPLEMENTATION, and REFERENCES. An optional section is STATUS.
A description of each section follows:
One line, describing the proposed new feature or change.
Metadata information: Maintainer, Date, Version, Mailing List, and Number.
Here is an example:
=head1 VERSION Maintainer: Nathan Torkington <[email protected]> Date: 30 Jul 2000 Version: 2 Mailing List: perl6-internals Number: 1
One or two paragraph summary of the problem and proposed solutions, or feature and probable implementations.
Detailed discussion of the problem or new feature.
Discussion of the possible implementations. This doesn't have to
be completely defined down to the
char *, instead enough to show
that it can be done.
A list of pointers to other documentation relevant to the topic. This could be other RFCs, internet standards, existing Perl or operating-system documentation, books, and so on.
Once an RFC is retired, the STATUS section is used to say why and how the RFC is dead.
Mail the RFC to
[email protected]. It will be assigned a
number if it doesn't already have one, then posted to the
perl6-announce mailing list, as well as the list in the
list metadata. They will also be archived at