Guacamole

I think it's noteworthy that the goal of that module is not to be able to parse all of Perl, just the subset of "standard Perl". So for example, it doesn't allow -bareword, stringy eval, unquoted hash keys on the left of the fat comma, and several more, but not because of technical limitations of the parser, but for policy reasons. I've suggested that the technical and policy based restrictions be disentangled to allow for easier porting of codebases to a parseable Perl, but I'm currently not sure when or if that might happen.

Of course also noteworthy is RPerl, which I believe implements its own parser.

unquoted hash keys on the left of the fat comma

That will rule out a lot of the Perl I read and pretty much all of the Perl I write. If that's a policy restriction rather than a technical one then I am at a loss to understand the reasoning behind it.

---

🦛

That will rule out a lot of the Perl I read and pretty much all of the Perl I write.

Yes, same here, and I commented on that in the issue I linked to above and Sawyer responded here. It doesn't seem to be a technical limitation.

Since I think it would be technically possible to parse something like my %hash = ( foo => -bar );, that also means that it would be possible to automatically transform that to my %hash = ( 'foo' => '-bar' );, for example if that's what the company coding standards happen to be. Update: However, the transformation requires a completely parseable Perl in the first place, which is what we don't have (yet).