On Thursday 22 February 2001 17:12, Dan Sugalski wrote:
> PDDs are for internals pretty much exclusively. If it doesn't involve the 
> implementation or design of the low-level guts of perl, it doesn't belong 
> in a PDD. Which isn't to say it has to all be C and bit-level things--the 
> parser wedges that can be written in perl would be specified in perl, of 
> course.
> Some random stranger should be able to take all the 'standard' PDDs 
> (however they're marked) and build a perl interpreter/compiler. That's 
> plan, at least.

I still think it's possible (and desirable) to have PDD that handles 
language issues.  We should certainly scope out beforehand exactly what the 
semantics of construct foo should be, even if it's just a BNC description 
and a quick explanation of how it behaves in void, scalar, and list context.
A lot of times this doesn't necessarily condense to the necessary bit 
twiddles.  Much of what Larry delivers, I imagine, will be of this scope.
A PDD like this a) provides an upfront idea of what the internals guys are 
supposed to produce.  ("I didn't know that foo could take a block") and b) 
provide a jumpstart to the perl6 deliverable documentation.

I think this is what Nathan was labelling a PLD, but I said in my other 
thread, I think a single vehicle can (and should) handle them both.

Then again, you may be considering that as internals anyway.

Many of the meta- items that will be Informational probably won't be 
internally-oriented, either, but I don't think that should stop us from 
documenting them.  IMO, the decision is how deliberate the segregation of 
the different areas.  Internals, language, and meta PDDs, while curently in 
a single PDD bucket, are sub-classed as such.  This allows both a 
comprehensive list (of PDD 0 - PDD X) as well as secondary collation by 
groups.  We could just as easily create PDDs, PLDs,  PMDs, as well, but 
it's harder to handle a comprehensive list that way.  You either have 
independent numbering schemes, which could lead to confusion, or a single 
numbering scheme, which begs the question of why seperate them in the first 

Bryan C. Warnock

Reply via email to