Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
On Fri, Sep 15, 2000 at 04:11:27PM -0600, Nathan Torkington wrote: > Mark-Jason Dominus writes: > > I think it would be a step in the right direction if the WG chairs > > actually required RFC authors to maintain their RFCs. > > In preparation for the end-run of RFCing, how about we compile a list > of "developing" RFCs that haven't been touched in more than a week, > and contact the authors to say "last chance, please finish up your > RFC now." > > Such a program would be easy to write (praise be to Date::Parse) and > would hopefully prod authors into incorporating feedback and closing > out their RFCs. > > Good idea? [time passes] I didn't use Date::Parse, but I did look for all RFCs still stting at v1 status. Since they're numbered chronologically, I cut off the bottom (anything submitted after 9/7). There are 100 RFCs in the list that follows. Code and data upon request. Z. - RFC : 3 v1; [Developing] Title: messages.rfc - An RFC to discussing the wisdom of allowing run time error and warning messages to be modified at run time Maint: Corwin Brust <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 1 Aug 2000 RFC : 7 v1; [Developing] Title: Higher resolution time values Maint: Gisle Aas <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 2000-08-02 RFC : 9 v1.0; [Developing] Title: Highlander Variable Types Maint: Andy Wardley <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 01 Aug 2000 RFC : 11 v1; [Developing] Title: Examples encoded with =also for|begin|end POD commands Maint: Barrie Slaymaker <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 02 Aug 2000 RFC : 12 v1; [Developing] Title: variable usage warnings Maint: Steve Fink <[EMAIL PROTECTED]> for now List : [EMAIL PROTECTED] Date : 2 Aug 2000 RFC : 13 v1; [Developing] Title: Creation of Copyright and Licensing Working Group Maint: S E[EMAIL PROTECTED] List : [EMAIL PROTECTED] Date : 2 Aug 2000 RFC : 15 v1; [Developing] Title: Stronger typing through tie. Maint: Michael Fowler <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 02 August 2000 RFC : 16 v1; [Developing] Title: Keep default Perl free of constraints such as warnings and strict. Maint: Daniel Chetlin <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 3 Aug 2000 RFC : 18 v1; [Developing] Title: Immediate subroutines Maint: Jean-Louis Leroy List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 19 v1; [Developing] Title: Rename the C operator Maint: J. David Blackstone <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 Aug 2000 RFC : 20 v1; [Developing] Title: Overloadable && and || Maint: Jean-Louis Leroy List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 21 v1.00; [Developing] Title: Replace C with a generic C function Maint: Damian Conway <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 22 v1.00; [Developing] Title: Builtin switch statement Maint: Damian Conway <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 24 v1.00; [Developing] Title: Semi-finite (lazy) lists Maint: Damian Conway <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 25 v1.00; [Developing] Title: Multiway comparisons Maint: Damian Conway <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 27 v1; [Developing] Title: Coroutines for Perl Maint: Tom Scola <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 28 v1 ; [Developing] Title: Perl should stay Perl. Maint: Simon Cozens <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : Aug 4 2000 RFC : 31 v1.00; [Developing] Title: Co-routines Maint: Damian Conway <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 4 August 2000 RFC : 32 v1; [Developing] Title: A method of allowing foreign objects in perl Maint: Dan Sugalski <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : August 02, 2000 RFC : 35 v1; [Developing] Title: A proposed internal base format for perl variables Maint: Dan Sugalski <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : August 04, 2000 RFC : 36 v1; [Developing] Title: Structured Internal Representation of Filenames Maint: Jarkko Hietaniemi <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 04 Aug 2000 RFC : 40 v1; [Developing] Title: Module Scope Control Maint: Bryan C. Warnock <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 5 Aug 2000 RFC : 43 v1; [Developing] Title: Integrate BigInts (and BigRats) Support Tightly With The Basic Scalars Maint: Jarkko Hietaniemi <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 05 Aug 2000 RFC : 44 v1; [Developing] Title: Bring Documentation Closer To Whatever It Documents Maint: Jarkko Hietaniemi <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 05 Aug 2000 RFC : 46 v1; [Developing] Title: Use features of portable, free compilers and libraries Maint: John Tobey <[EMAIL PROTECTED]> List : [EMAIL PROTECTED] Date : 5 Aug 2000 RFC : 47 v1; [Developing] Title: Universal Asynchronous I/O Maint: Uri Guttman <[EMAIL PROTECTED]> List : [EMAIL PRO
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
Chaim Frenkel writes: > We are not at that stage yet. > > There are too many new things that are _supposed_ to interact to > bother with a prototype. It doesn't do any good, until the language > is nailed down. That's no argument against prototyping, though. Prototype one feature and then you can prototype any feature that uses it. You have to start somewhere, or you'll never start. > You position is _perfectly_ and absolutely the only one that should be > taken _ONCE_ the p6 code base has firmed up and is past the feature > freeze phase. Not necessarily. Yes, we'll want to prototype things to answer questions about their performance or semantics, but there's no reason not to prototype things now. Prototypes now have several benefits, in fact: - show what can be done - provide a basis to test and define interactions with other features, which is hard to do in the abstract - save us work later on I'm not saying I think they should be mandatory, but an RFC with a prototype behind it certainly carries more weight in my mind than an unprototyped RFC. Nat
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
Mark-Jason Dominus writes: > I think it would be a step in the right direction if the WG chairs > actually required RFC authors to maintain their RFCs. In preparation for the end-run of RFCing, how about we compile a list of "developing" RFCs that haven't been touched in more than a week, and contact the authors to say "last chance, please finish up your RFC now." Such a program would be easy to write (praise be to Date::Parse) and would hopefully prod authors into incorporating feedback and closing out their RFCs. Good idea? Nat
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
On Tue, Sep 12, 2000 at 05:44:38PM +1100, [EMAIL PROTECTED] wrote: > Schwern wrote: > > Seperating the men from the boys. > > I'll just go get my detachable penis :) That's easily solved with the Tie::Penis module. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Sometimes these hairstyles are exaggerated beyond the laws of physics - Unknown narrator speaking about Anime
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
Schwern wrote: > Seperating the men from the boys. I'll just go get my detachable penis :) K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
> RFC - Prototype RFC Implementations - Seperating the men from the boys. Feh. Scuse me while I find my detachable penis. K. -- Kirrily Robert -- <[EMAIL PROTECTED]> -- http://netizen.com.au/ Open Source development, consulting and solutions Level 10, 500 Collins St, Melbourne VIC 3000 Phone: +61 3 9614 0949 Fax: +61 3 9614 0948 Mobile: +61 410 664 994
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
> Bad reasons > I do not have time. > I do not have the tuits. I think it would be a step in the right direction if the WG chairs actually required RFC authors to maintain their RFCs.
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
On Mon, Sep 11, 2000 at 05:38:59PM -0400, John Porter wrote: > Maybe ALL of p6 should be prototyped using one giant filter? That would be basically what the p52p6 translator will be. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Cheating is often more efficient. - Seven of Nine
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
On Mon, Sep 11, 2000 at 05:30:01PM -0400, Chaim Frenkel wrote: > We are not at that stage yet. We're so far into that stage that its starting to rot. We have 209 seperate feature ideas. That's plenty to start getting serious. Just because we start thinking seriously about implementation details *doesn't* mean others cannot continue brainstorming. > There are too many new things that are _supposed_ to interact to > bother with a prototype. It doesn't do any good, until the language > is nailed down. Consider these like unit tests. You want to make sure each piece works seperately before you try to put them all together. Also, it may be possible to combine several prototype implementations together and see what happens. > You position is _perfectly_ and absolutely the only one that should be > taken _ONCE_ the p6 code base has firmed up and is past the feature > freeze phase. At that point it is too late and pointless to produce prototypes. The feature freeze must come before or very earily in coding (else how do you know what to code?). Once the code base has firmed up, it will be too late to find fundemental problems with the features. Its the difference between catching a mistake during architecture and catching it during construction. 100 times difference. Prototypes are *cheap* compared to the cost of noticing a mistkae during construction. > Lets work on firming up the specs and ironing out differences. That's the whole point of prototyping. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse It's time for my sponge bath and I'm feeling very, very dirty. -- Toothgnip www.goats.com
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
At 05:30 PM 9/11/00 -0400, Chaim Frenkel wrote: >Up until that point, it is wasted energy. At this point, without code >there is nothing locked down, no cost in changing. (Yes, even though >they are bits, changing software, changing architecture has major >costs.) Don't forget that changing architecture has costs, even without code backing it yet. There's still the mental costs of refiguring how it all fits together. (And it does all need to fit together--if the mental model's a kludged up hack, the implementation will be too) This isn't to argue against making changes and reworking things, mind. Just pointing out that all changes have a cost. Dan --"it's like this"--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
Michael G Schwern wrote: > > -*> SOURCE FILTERS <<< Oh, yes. Damn. I forgot about filters. :-( Sorry, one and all. Maybe ALL of p6 should be prototyped using one giant filter? -- John Porter
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes: MGS> If the idea behind the RFC is good enough, not having time or tuits MGS> should not be a problem, as its inherent err... "goodness" should MGS> attract those who have time and tuits. Even if the RFC is marginal MGS> but provocative, the resulting controversial discussion around it MGS> should be easily nudged into creating prototypes. The rivals can be MGS> asked to put their ideas into code and pit the two against each other. We are not at that stage yet. There are too many new things that are _supposed_ to interact to bother with a prototype. It doesn't do any good, until the language is nailed down. You position is _perfectly_ and absolutely the only one that should be taken _ONCE_ the p6 code base has firmed up and is past the feature freeze phase. Up until that point, it is wasted energy. At this point, without code there is nothing locked down, no cost in changing. (Yes, even though they are bits, changing software, changing architecture has major costs.) Lets work on firming up the specs and ironing out differences. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
On Mon, Sep 11, 2000 at 04:38:01PM -0400, John Porter wrote: > You have not addressed my (and I suspect many others') greatest concern: > I am not a p5 hacker; nor am I a p6 hacker by dint of the fact that p6 does > not yet exist. Can I write the prototype in pseudocode? Or should I be > building on Topaz? :-/ > > And what of prototyping syntactic features? ARGH! For the 2239829th time, YES! Its even in the RFC! "Prototypes can be written as modules, wrapper scripts around Perl 5, Filter.pm modules, Perl5 core patches, etc..." -*> SOURCE FILTERS <<< Everybody see it now? Filter.pm is an amazingly flexible tool allowing you to muck with Perl syntax to your heart's content. If you haven't yet, read the perlfilter man page before going any further in this discussion. All should be clear. You can radically alter the syntax and behavior of Perl with Perl. There is also Function::Override to aid in the alteration of the behavior of core functions. On top of that, operator overloading is helpful. Lingua::Romana::Perligata is a perfect example of how insanely far Perl 5 can be dragged, unfortunately, it not officially released yet. If anyone has the CD from TPC it should be on it. Switch.pm also makes use of source filters to alter syntax. Quantum::Superpositions is an excellent example of implementing a fully-functioning prototype while missing a vitual piece of the system (that being, a quantum supercomputer). For a bare simple, stupid example of a source filter, Semi::Semicolons is about as simple (and stupid) as you can get. I just implemented a prototype for RFC 208 (crypt with default salt). It took me about 15 minutes. (http://www.pobox.com/~schwern/src/RFC-Prototype-0.01.tar.gz) I must admit, this was a very trivial example of prototyping, but there ya go. Even this simple bit of code will help to flesh out issues of configuring the salt on various OS's. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Sometimes these hairstyles are exaggerated beyond the laws of physics - Unknown narrator speaking about Anime
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
Michael G Schwern wrote: > > The main thing I wish to accomplish here is to change the prevailing > attitude from "write an RFC and maybe something will come of it" to > "write an RFC and make sure something comes of it." Move the ball > down the field. Eminently reasonable. > I wish to make the default "put up or shut up", but there will be > outs. You just have to give a good reason why you can't implement a > prototype. > > Good reasons > Its technically infeasible to write a prototype (RFC 1) > The prototype will take an inordinate amount of time. (RFC 1) > This RFC is an idea/manifesto style RFC (RFC 13) > > Bad reasons > I do not have time. > I do not have the tuits. You have not addressed my (and I suspect many others') greatest concern: I am not a p5 hacker; nor am I a p6 hacker by dint of the fact that p6 does not yet exist. Can I write the prototype in pseudocode? Or should I be building on Topaz? :-/ And what of prototyping syntactic features? You want everybody to hack yacc? You know as well as I do that every bit of yacc thus created will be non-integrable, and thus so much excelsior. Not to mention the fact that everyone will be expending duplicative effort cobbling together scaffolding grammar from which to hang their good bits. Not to mention that fact that most people can't write yacc either. Is plain EBNF acceptable? -- John Porter We're building the house of the future together.
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
On Mon, Sep 11, 2000 at 04:06:49PM -0400, John Porter wrote: > Michael G Schwern wrote: > > Its all flexible. I forgot to put my usual "there will be exceptions" > > clause into the RFC. > > If I'm allowed to interpret it to mean "There IS no Rule #6", > then everything's dandy. The main thing I wish to accomplish here is to change the prevailing attitude from "write an RFC and maybe something will come of it" to "write an RFC and make sure something comes of it." Move the ball down the field. I wish to make the default "put up or shut up", but there will be outs. You just have to give a good reason why you can't implement a prototype. Good reasons Its technically infeasible to write a prototype (RFC 1) The prototype will take an inordinate amount of time. (RFC 1) This RFC is an idea/manifesto style RFC (RFC 13) Bad reasons I do not have time. I do not have the tuits. Yes, this means that RFC authors are going to have to invest some time into their RFCs beyond the initial write-up if they expect them to fly. Your idea becomes your pet project and you are ultimately responsible for pushing it forward. If you can find someone else to tkae over that pushing (a White Knight, a working group leader, etc...) fine. If the idea behind the RFC is good enough, not having time or tuits should not be a problem, as its inherent err... "goodness" should attract those who have time and tuits. Even if the RFC is marginal but provocative, the resulting controversial discussion around it should be easily nudged into creating prototypes. The rivals can be asked to put their ideas into code and pit the two against each other. Sometimes just saying "there's no way we can prototype this" will generate a prototype by nature of the implied challenge to do the impossible. If no discussion and no tuits can be found to prototype an RFC, then I guess it wasn't terribly interesting in the first place. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse come sing my fun song my bologna has a first name p a s t e -- Fmh
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
Michael G Schwern wrote: > On Mon, Sep 11, 2000 at 02:29:47PM -0400, John Porter wrote: > > No. You can not oblige the RFC maintainer to write the prototype or > > cat-herd someone else into it. The vast majority of RFC authors > > (myself included) would simply not be up to such an order. > > Its all flexible. I forgot to put my usual "there will be exceptions" > clause into the RFC. If I'm allowed to interpret it to mean "There IS no Rule #6", then everything's dandy. -- John Porter We're building the house of the future together.
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
On Mon, Sep 11, 2000 at 02:29:47PM -0400, John Porter wrote: > No. You can not oblige the RFC maintainer to write the prototype or > cat-herd someone else into it. The vast majority of RFC authors > (myself included) would simply not be up to such an order. > > Instead, it should be the WG lead's responsibility to ensure that each > accepted RFC gets a prototype (*EVENTUALLY*), assigning an implementor > if necessary. Each working group will probably want to deal with marshelling their forces to deal with RFCs in their own way. If the WG leader wants to handle it, fine. This all falls under the category of "find someone who does". Its all flexible. I forgot to put my usual "there will be exceptions" clause into the RFC. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Ladies and gentlemen, do not be alarmed. Please remain perfectly still. What you are about to see is real. The performers are not grinning scarecrows sent here to torture and manipulate you.
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
Michael G Schwern wrote: > Chaim Frenkel wrote: > > > > At this point, I think this is too strong. My understanding of Larry's > > intention is that we are now brainstorming. Brainstorming can not work > > if folks will pre-filter their ideas. Part of the effect is a half-baked > > idea on another member of the brainstorming group. (I've seen some of > > the effect in Damian's responses) > > "RFCs should be *FOLLOWED BY* a prototype implementation" > > "...each RFC should *EVENTUALLY* be accompanyed by a prototype > implementation" > > I'm not stating that each RFC should come with a prototype, but that > one should be forthcoming as part of its development process. > > "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." > > If you can't find the tuits to write the prototype, how are you going > to find them to write the implementation? No. You can not oblige the RFC maintainer to write the prototype or cat-herd someone else into it. The vast majority of RFC authors (myself included) would simply not be up to such an order. Instead, it should be the WG lead's responsibility to ensure that each accepted RFC gets a prototype (*EVENTUALLY*), assigning an implementor if necessary. -- John Porter We're building the house of the future together.
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
On Mon, Sep 11, 2000 at 12:57:47AM -0400, Chaim Frenkel wrote: > > "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes: > > MGS> =head1 ABSTRACT > > MGS> RFCs should be followed by a prototype implementation of their > MGS> proposal which provides something concrete to develop the RFC from and > MGS> helps to avoid endless discussion. > > At this point, I think this is too strong. My understanding of Larry's > intention is that we are now brainstorming. Brainstorming can not work > if folks will pre-filter their ideas. Part of the effect is a half-baked > idea on another member of the brainstorming group. (I've seen some of > the effect in Damian's responses) "RFCs should be *FOLLOWED BY* a prototype implementation" "...each RFC should *EVENTUALLY* be accompanyed by a prototype implementation" I'm not stating that each RFC should come with a prototype, but that one should be forthcoming as part of its development process. > What do you do with folks, that aren't core hackers? As pointed out in the RFC, many can be prototyped as straight perl 5 modules or source filters. Additionally... "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." If you can't find the tuits to write the prototype, how are you going to find them to write the implementation? > Or with simply wish lists? What about the pet peeves list that was > being generated? These aren't implementation issues but another set > of users to be accounted for. As mentioned "special cases exist. An RFC for which no prototype can be written (RFC 16, for example)..." also RFC 1 was given as an example of an exception. > And the fact that you are allowing some RFCs to go without a prototype > puts this into the _we need an RFC Czar_ tyranny mold. Yes, it will require somebody to keep track of the continuing development and quality of the RFC. Probably Ask or Ziggy. It will be their job to make sure that RFCs and their prototypes continue to progress, or if the RFC is complete, or if the RFC requires an exception. This isn't going to require any Iron Fisted, Shoe Pounding dicatorship, but somebody's got to keep things sorted. Do not equate organization with tyranny. > Let the ideas flow for a while, and then let's go back over them > for fine-tuning or rejection. Its been long enough, time to get some order into the chaos. Brainstorming has been going on for nearly two months, the discussion has already begun on how to advance beyond it and the issue of the large volume and low quality of the RFC list has come up. This proposal will not stop the flow of ideas. It will stil be a simple matter to write and post an RFC. What it does is provide a way to funnel and solidify the efforts to develop the RFC and to ->eventually<- weed out idle thoughts, undeveloped proposals and Bad Ideas. -- Michael G Schwern http://www.pobox.com/~schwern/ [EMAIL PROTECTED] Just Another Stupid Consultant Perl6 Kwalitee Ashuranse Any failure I encounter in life is the fault of android weasels. -- everything i ever needed to know i learned from goats
Re: RFC - Prototype RFC Implementations - Seperating the men from the boys.
> "MGS" == Michael G Schwern <[EMAIL PROTECTED]> writes: MGS> =head1 ABSTRACT MGS> RFCs should be followed by a prototype implementation of their MGS> proposal which provides something concrete to develop the RFC from and MGS> helps to avoid endless discussion. At this point, I think this is too strong. My understanding of Larry's intention is that we are now brainstorming. Brainstorming can not work if folks will pre-filter their ideas. Part of the effect is a half-baked idea on another member of the brainstorming group. (I've seen some of the effect in Damian's responses) What do you do with folks, that aren't core hackers? Or with simply wish lists? Reject them because they aren't prototyped? What about the pet peeves list that was being generated? These aren't implementation issues but another set of users to be accounted for. And the fact that you are allowing some RFCs to go without a prototype puts this into the _we need an RFC Czar_ tyranny mold. Let the ideas flow for a while, and then let's go back over them for fine-tuning or rejection. -- Chaim FrenkelNonlinear Knowledge, Inc. [EMAIL PROTECTED] +1-718-236-0183
RFC - Prototype RFC Implementations - Seperating the men from the boys.
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 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 filt
