Re^9: POD Meditation?

[JavaFan]

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.

[LanX]

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.

[JavaFan]

to fix what you consider a bug.

Did I mention anywhere there's a bug?

I'm just stating what is happening. That the trick the OP quotes only works because POD parsers are stupid, and don't look at context.

nobody will ever dare to deprecate what you consider to be wrong.

Again, you seem to make up words and ideas out of thin air.

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.

What "tolerance"? Note that Perl doesn't require empty lines; it's the POD parsers that do. That fact is even mentioned in perlsyn:

   Note that pod translators should look at only paragraphs beginning with
   a pod directive (it makes parsing easier), whereas the compiler
   actually knows to look for pod escapes even in the middle of a
   paragraph.  This means that the following secret stuff will be ignored
   by both the compiler and the translators.

       $a=3;
       =secret stuff
        warn "Neither POD nor CODE!?"
       =cut back
       print "got $a\n";

   You probably shouldn’t rely upon the "warn()" being podded out forever.
   Not all pod translators are well-behaved in this regard, and perhaps
   the compiler will become pickier.

Hmm, that last sentence seem to be at odds with your so we have to accept the new standard..

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.

I'd think most people in this case will prefer KISS over DRY. I certainly hope so.