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
the
> 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
place.
--
Bryan C. Warnock
[EMAIL PROTECTED]
