Sean M. Burke wrote:
> However, I do at times wonder why anyone in their right mind would
> write /another/ perlpodspec-compliant Pod-parser. Doing the first
> one, Pod::Simple, was plenty hard enough.
In which case we have this situation:
1 There's the 'theoretical' Pod spec, which isn't used anywhere.
2 There's a single Pod parser which is used by everybody and
implements an 'improved' version of the spec.
There doesn't seem much point in having this division if the first isn't
actually implemented anywhere. (And having it around allows for the
possibility, however unlikely, that somebody might implement it and for
incompatibilities to ensue.)
I reckon it'd be saner to have one of these situations:
* When an extra feature is added to Pod::Simple, it also gets added to
the spec (even if only in an appendix of "things you can get away
with but probably shouldn't") so that anybody else trying to write a
parser becomes aware of them.
* It becomes decreed that Pod::Simple defines canonical Pod (and
anybody else wanting to write another parser has to mimic its
behaviour). The perlpodspec doc is kept as it is now, such that
anybody who follows it will produce valid Pod. (That is, it's a
one-way relationship: following perlpodspec yields valid Pod, but
it's not the case that all the redundant and/or arcane bits of valid
Pod are in that doc. The doc is good enough for people wanting to
write Pod, but not for somebody wanting to write another parser.)
> I can't think of a motivation that'd be worth the bother of doing it
> all over again.
Still probably better not to leave the door open though.
I can't right now think of a reason why somebody would write another
Parser in Perl, but they might do it in 'Emacs Lisp' or the 'Vim' macro
language to help with syntax colouring or other Pod-editing facilities.
Smylers
