I agree with Dan's proposals for PDDs. In particular I like the idea of
the WG chairs having decision power -- it should protect us somewhat from
design-by-committee syndrome.
However, I don't want to see early (premature) adoption of fundamental
pieces like the VM or parser. It makes sense to me to explore many possible
designs and pick and choose between them. Also, if we can keep external API
design separate from internal design I think we'll have more wiggle room
to experiment. (That's one of the big problems with perl 5 right now.)
One issue with the language RFC process that Larry and Mark-Jason Dominus
have discussed is inconsistency. (I still can't figure out whether it's a
strength or weakness.) We should do a better job of telling people about
how our PDDs fit into the bigger picture. I propose that all PDDs state
which other PDDs they require, which they supersede and which they conflict
with. This will make it a lot easier to identify coherent designs.
Dan Sugalski wrote:
> 2) We start counting from 2. (RFCs 0 and 1 are reserved, in case anyone
> beats me to them)
(I thought you said they were PDDs... ;)
Why don't you just quickly issue several PDDs on the subjects that you
want to reserve. They can be skeleton documents that just contain the
sections you want us to write. (I hope that the numbers 0 and 1 aren't
important -- they might be superseded by PDD 16 and 23...)
> 3) The format of the previous RFCs will be followed. The implementation
> section is optional, though strongly encouraged where appropriate.
I disagree. An implementation section is mandatory for a PDD. Anybody
that can't bother to take the time to sketch out a *possible* implementation
hasn't thought deeply about the subject. Anything without an implementation
section is just a draft. If a PDD is a proposal for an API, then most of
the PDD is the implementation section!
- Ken
