in reply to Re^2: Combining Import and Source-Filter to implement Syntactic Macro mechanism
in thread Combining Import and Source-Filter to implement Syntactic Macro mechanism

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?

  • Comment on Re^3: Combining Import and Source-Filter to implement Syntactic Macro mechanism

Replies are listed 'Best First'.
Re^4: Combining Import and Source-Filter to implement Syntactic Macro mechanism
by LanX (Saint) on Feb 20, 2019 at 00:18 UTC
    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

[reply]

In Section Seekers of Perl Wisdom