| [reply] |
In my first message in this thread, I wrote:
Because POD parsers actually don't parse POD. They parse anything between ^=\w and ^=cut, without looking at context, assuming to capture all the POD (and nothing but the POD).
Do your contributions contradict that, or somehow add additional insight?
Really, I fail to understand what point you're trying to make.
My point is, "POD parsers are stupid, they don't know context", and all you've done so far is add more examples of this.
| [reply] |
Saying "POD parsers are stupid" implies somehow "They could be different".
This will never happen, because:
1. "Only Perl can parse Perl". It's very unlikely that POD parsing will ever be included into the Perl parser, to fix what you consider a bug. Hence we get a similar situation "Only POD can parse POD".
2. Even if the OP's code case was ... let's say "broken" POD ... by Larry's original intention (which I can't clearly read from the cited "specifications"), we have a de facto standard now. Too many people rely their applications on the simple but efficient parsing logic of POD parsers and nobody will ever dare to deprecate what you consider to be wrong.
(Another example of a "misuse" effectively becoming standard is the tolerance regarding empty lines surrounding =statements. Nobody will ever be able to enforce the original rules here so we have to accept the new standard.)
Is my point clearer now?
UPDATE: Last but not least.
3. The possibility to have "dual" code evaluated by both parsers is a genius possibility to produce documentation in a DRY way, most people won't ever want to miss again.
| [reply]
[d/l] |