This makes them so useful.

Introducing an external parser for Perl would effectively reduce the approach to the same level of reliability like classic source filters.

I'd rather live with that limitation.

Edit

Fwiw: I already tried combining this approach with Keyword::Simple, but this is hindered by an internal bug.

Hey LanX,

Sounds like you want to avoid a Perl parser within Perl here, but honestly, PPI is pretty well the only thing that can parse Perl as closely as perl itself.

What's your true objective here? If we're avoiding certain things, what things are acceptable?

Perhaps your end objective isn't clear. Could you elaborate?

PPI is nice for static parsing, but this should work in any dynamic context. (Just think about an imported sub using prototypes, and hence dynamically altering the parsing rules)

Let me pick one out of all the problems source filters have:

Combining them with others, or even nesting them.

They try to parse a whole file globally and introduce code at a distance. The next filter sees that output and is confused. The resulting problems are a nightmare to debug.

This can't happen here.

That's why macros are such a powerful tool in the lisp world.

Of course they should be used with care and have pitfalls ( see "hygienic" macros), but that's a problem all code generation has.

There are many longer elaborations about the limitations of source filters, I'd like to point you there.

Cheers Rolf
_{(addicted to the Perl Programming Language :)
Wikisyntax for the Monastery FootballPerl is like chess, only without the dice}