Jonathan Lang wrote:
> 2. Getting block comments to hide POD blocks wouldn't require the POD
> parser to have a full implementation of a Perl parser. It would
> require the POD parser to have a _limited_ implementation of a Perl
> parser, one that's capable of identifying block comments. And IIRC,
> you already have to do something like this with respect to block
> quotes:
Actually, the POD parser would have to be a fairly complete Perl parser.
As your example shows:
>
> say :to(END);
> =begin POD
> blah blah blah
> =end POD
> END
>
> If I understand matters correctly, the "POD code" in the above example
> isn't POD code at all, but rather the content of a multi-line quote.
> So extending the POD parser's awareness of Perl syntax to handle block
> comments as well isn't much of a stretch.
If *I* understand matters correctly, Perl 6 will see that as identical to
say :to(END);
END
*because* we want the POD parser be simple, rather than an
almost-complete parser of Perl. After all, there are many ways to "hide"
POD-like text in Perl.
You might think, "Well, how hard is it to look for ":to(XYZ)" followed
by a line containing XYZ?" Going beyond the fact that there are actually
quite a few ways to spell ":to(XYZ)", Perl code that generates Perl code
will trip you up:
say "say :to(END);";
say "Here's my text";
say "=begin comment";
say "My auto-generated code even contains comments on it's strings!"
say "=end";
say "More of my text";
say "END";
You have to parse all string syntaxes to avoid that pitfall. And once
you take care of that issue, you have to handle the problem of parsing
Perl code that's trying to parse Perl code, looking for say statements
that use here-doc syntax containing POD comments:
my $checker = regex {
say \s* \: to \( \w+ \) ; $ # match a say with here-doc
(
<! \s* $1 > .* $
)* # match any lines that don't start with $1
=for comment # match the beginning of an embedded POD comment
}
(No, I don't approve of the indentation of that example. But should your
program fail just because somebody doesn't follow good style?)
And once you've extended the parser to handle *that* case, Finagle's Law
dictates that someone will put the above code sample into a Perl string
literal!
In summary:
As your example pointed out, the POD parser would have to handle all the
various string syntaxes of Perl 6. Then, there is also regular
expression syntax that has to be covered. And who knows what else I'm
overlooking?
Compare that with the simplicity that $larry & $damian are promoting.
Yes, it'll be a pain to get the effect you *wanted* from
> say :to(END);
> =begin POD
> blah blah blah
> =end POD
> END
but the cost to the POD parser is just not worth it.
=thom
-----
Finagle's Law: the perversity of the Universe tends towards a maximum.
