At 10:19 AM 11/17/00 -0800, Ken Fox wrote:
>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.)
That's one of the reasons I'd like to work on the APIs first. I realize
that doing even that will have an effect on the design of the pieces behind
the APIs, but we have to startsomewhere.
>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.
That's one place where the PDD process and the earlier RFC process will
differ. Docs that make PDD 'developing' status or better are real design
documents for what'll ultimately be perl 6. Most of the brainstorming work
I'd like left on the mailing lists, or in informational PDDs. (And I'd like
to try and keep those reasonably relevant)
>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... ;)
D'oh! :)
>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...)
They're policy/philosophy/broad-outline docs, so they're unlikely to be
replaced anytime soon.
> > 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!
No PDD's going in without someone responsible giving it the nod, so I'm not
worried about drafts getting in without a good reason. And one of the
reasons that the implementation section's optional is that I don't see a
reason to enforce it for PDDs that specify APIs, for example. Code and/or
algorithms for those (along with things like the bytecode PDDs) seem rather
superfluous.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
