Re^3: On Parsing Perl (Once upon a time)

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.

Comment on Re^3: On Parsing Perl (Once upon a time) Download Code

Replies are listed 'Best First'.

Re^4: On Parsing Perl (Once upon a time)
by LanX (Saint) on Jul 11, 2022 at 15:05 UTC

> 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}

[reply]
[d/l]
[select]


The stupid question is the question not asked
	PerlMonks