NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Mark Hahn, <hahn@neurocog.lrdc.pitt.edu>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
A few disclaimers are necessary there... (Score:2)
If you do any transformation, you will not know that you've misparsed. You'll simply get the wrong result, and you will damage code.
I know you're hinting at it with your definition of "parse" caveat there, but I think it deserves a better
Re:A few disclaimers are necessary there... (Score:1)
And since there _is_ no language definition by which to define Perl, we simply say that "What perl parsers is what Perl is".
What is the definition of sub'new {}?
It's sub main::new {}. Is that a bug? It can't possibly be, because Perl is what perl parses.
If you look beyond the issue of whether PPI "parses" Perl correctly, you'll see that "there is no spoon".
There is no Perl, and everything (including perl itself) is merely doing something based on it's approximation of what it thinks Perl is.
PPI "parses" a fixed-length array or bytes of something that by most people's definitions is "Perl" into a document model based on only syntax.
It can't execute it or handle code as a stream.
perl "parses" a stream of bytes of something that by most people's definition is "Perl" and executes it as it goes, some of the time assembling byte code or symbol tree entries.
perl can't understand it as a document and it can't handle it as a fixed-length array.
So now there are two approximations of Perl. The one perl does, and the one that PPI does. The big question was, can we get the two close enough to make a difference.
And the answer is yes.
Reply to This
Parent