in reply to Re^2: Perl not BNF-able??
in thread Perl not BNF-able??
Since I wrote PPI, I probably have struggled against more anti-BNF things that most. So here's a few.
1. Source Filters
2. BEGIN blocks
You can't (code) parse Perl without also executing it.
3. Cannot be parsed when isolated
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.
1. Source Filters
You can't handle source filters in BNF for obvious reasons.use Acme::Buffy; BuFFy BUFfy bufFy Buffy...
2. BEGIN blocks
You can't (code) parse Perl without also executing it.
That code is legal Perl every day of the year except for Christmas, when it is not legal Perl code.BEGIN { die if is_christmas($today); }
3. Cannot be parsed when isolated
That code could mean either function('foo'), 'bar' or function( 'foo', 'bar' ) depending on what is in the Some module.use Some 'function'; function 'foo', 'bar';
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.
|
---|
In Section
Seekers of Perl Wisdom