Yes, thank you for that - PPI looks like the best approach so far and PPI::Dumper seems very useful for identifying the context interpretations previous posts show concern about.
| [reply] |
But keep in mind that PPI is just guessing, some of the time, using the most likely parsing, rather than an absolute parsing. So, it's still not formal or official, it's merely workable on most programs. But there's no way to know in the code if it's ever done the wrong thing... you simply get a wrong parse and no indication.
| [reply] |
Since I wrote PPI, I probably have struggled against more anti-BNF things that most. So here's a few.
1. Source Filters
use Acme::Buffy;
BuFFy BUFfy bufFy Buffy...
You can't handle source filters in BNF for obvious reasons.
2. BEGIN blocks
You can't (code) parse Perl without also executing it.
BEGIN {
die if is_christmas($today);
}
That code is legal Perl every day of the year except for Christmas, when it is not legal Perl code.
3. Cannot be parsed when isolated
use Some 'function';
function 'foo', 'bar';
That code could mean either function('foo'), 'bar' or function( 'foo', 'bar' ) depending on what is in the Some module.
If Some.pm isn't installed on your machine, how are you to know.
PPI does what it does using more evil than Perl itself, and certainly more heuristics. It makes up for it's guesses by promising that what it writes out is ALWAYS character for character identical to what it read in, unless you change something.
So if it has a problem, it won't break as long as you don't change that part of the tree.
There's probably more reasons, but for me those are the big three.
| [reply]
[d/l]
[select] |
