On Wed, Oct 04, 2000 at 11:00:55PM +0100, Simon Cozens wrote:
On Wed, Oct 04, 2000 at 03:42:57PM -0500, Jarkko Hietaniemi wrote:
Too many RFCs live in a vacuum by not not explaining in enough detail
what is the problem they are trying to solve, but instead go ahead and
pull new/backward-incompatible syntax and/or keywords and/or semantics
out of thin air.
This skirts, but does not *quite* touch on, the *REAL* failure of the
RFC process. The real failure, as I see it, is this: We can only tell
whether an RFC is officially good or officially stoopid when Larry casts
his vote on it. And that only happens once all the RFCs have been
completed.
*This* RFC process was about brainstorming, and about totally
rethinking what Perl can be. It was designed to get the bizarre
ideas out there (like currying and lazy evaluation) to see how
we could best extend Perl.
The *next* RFC process (assuming there is one for the development
of p6) will need to strongly discourage wild brainstorming and
strongly encourage Real Work (tm), including real proposals on how
to solve hard problems, which will find their way into implementation.
It sounds like your request is to add a CFV mechanism to RFCs, once
there are teams working on the various aspects of Perl6. Suggestions?
(Hint: think about core teams.)
This makes it nearly impossible to build ideas on top of previous RFCs,
since you don't know if you're building on rock or sand;
Assume the 362 RFCs in the repository don't exist. Assume that the
few that are being accepted are part of a new RFC effort. And assume
that those are solid, or are easily made solid.
To be more specific: Perl isn't something you can separate out into
discrete blocks; two proposals are very, very infrequently independent.
There are going to be people focusing on QA, and others focusing on regexes.
Discussing why one QA proposal has merit is orthogonal to its use
on writing test cases for regexes. Once that QA proposal is accepted,
it intertwines itself into regex test cases.
Z.
