Static parsing is only reliable, if you rule out or control all imported subs, because prototypes change the way Perl is parsed.

I think, though, that prototypes aren't the only reason Perl isn't statically parseable. There are quite a few heuristics that the parser uses that aren't all too well documented, and I'm not sure if a static parser would be able to reimplement all of them. And then there is no strict code, which I think gets even trickier. At some point I was considering researching and making a list of all of the reasons, but I unfortunately never got around to it.

> There are quite a few heuristics that the parser uses that aren't all too well documented,

I agree, it's messy. But that's a matter of research.

For instance I was bitten when operator overloading of < and > became unreliable, because the parser thought that < is the start of a <> iterator.

I also remember a time where this was legal syntax

for qw/a b c/ {

}
[download]

and BTW this is a list multiplication, even without parens around

qw/a b c/ x 3

> At some point I was considering researching and making a list of all of the reasons, but I unfortunately never got around to it.

I think this could be solved by an automatic approach training an external parser against automatically created code and snippets harvested from CPAN.

The test would pass if (a patched) B::Deparse created the same syntax tree after compilation.

Many people already invested time in parsers ( I could name at least half a dozen projects), those tests could be used too.

As a side product, P5P would get a proper test suite too.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery}