Larry Wall wrote:
I have a problem with both extremes, and I want to solve it with a dose of postmodern apathy. It may seem a bit insane, but I think that inprint qq:to/END/ =for whatever END I would prefer that the =for is considered Pod by any standard Pod parser, but is *not* considered Pod by the Perl 6 parser. And I think that's just fine. If the programmer really wants to put Pod in a string, they can just be responsible for stripping it out themselves. And a standard Pod parser shouldn't be expected to parse full-up Perl.
Summary: Perl treats quoted Pod as quoted text, and all other Pod as comments; Pod treats all Pod as Pod. Effects: 1. You trade the brutally surprising behavior of whole lines of string literal content vanishing for the much more subtle surprising behavior of whole lines of string literal content being available via $=pod variables (some might consider the latter to be a feature). 2. Pod Sections behave just like block comments (aside from the pod variables thing), which is very nice. 3. There will be a few rare cases where the Perl programmer will need to cheat to keep something that looks like Pod from registering as Pod; this will be easy enough to do when it's needed. Opinion: That's a significant trade up, and addresses my biggest concerns. -- The only other thing that I'll continue to lobby for is that the line starting with a block comment's termination tag should _not_ be considered part of the comment, save for the termination tag itself. Programmers are likely to be surprised when text that follows a closing bracket is treated as being included within it. -- Jonathan "Dataweaver" Lang
