4 ms·

You can do a lot in Perl with just closures and setting package slots etc., that you would need to use macros for in say Lisps. Still, I agree, there's no real

You can do a lot in Perl with just closures and setting package slots etc., that you would need to use macros for in say Lisps. Still, I agree, there's no real AST and string eval is unsafe and parsing is a real issue. I've started https://metacpan.org/pod/FP::AST::Perl https://metacpan.org/pod/FP::AST::Perl (very unfinished) to solve the code generation issue and hope to generate an AST from the op tree (not sure how feasible, will see). Feel free to tell me (here or offline) what your use case is and whether that module might suit you.

lloeki 7y ago
> There’s no real AST Perl cannot be statically parsed! > Theorem: Parsing Perl 5 is Undecidable https://www.perlmonks.org/index.pl?node_id=663393 https://www.perlmonks.org/index.pl?node_id=663393
- pflanze 7y ago
  > Perl cannot be statically parsed! My usage (modifying syntax / extending the compiler when running Perl programs) doesn't need static parsing. What I need is a way to leverage the existing infrastructure in the interpreter for parsing in a way that's compatible with most modules/usages. AFAIK the parser in perl goes directly from source to an OP tree (modulo running other Perl code on the go that modifies the parsing state, which is the reason for the undecidability), it would be cool if it didn't go to an OP tree but something more AST instead, but it might not be feasible to change perl to do that because of modules working on the op tree (if anyone wants to help figure out how much this is true, please do); because of that I'll instead look into converting the op tree into an AST. I've been told the op tree does have additional info that might make that feasible. Notabene, B::Deparse exists, which is somewhat of a proof that this works, although there are limitations, whether they matter is part of what I need to find out.
  - lloeki 7y ago
    Haha, my comment was definitely tongue in cheek ;) I fully expect most of properly written Perl code to be statically parseable into an AST, save for pathological cases (and I fully expect a proper rubocop-like Perl linter to highlight such ambiguities, and would reject them in any sensible project)

lloeki 7y ago

> There’s no real AST Perl cannot be statically parsed! > Theorem: Parsing Perl 5 is Undecidable https://www.perlmonks.org/index.pl?node_id=663393 https://www.perlmonks.org/index.pl?node_id=663393

pflanze 7y ago
> Perl cannot be statically parsed! My usage (modifying syntax / extending the compiler when running Perl programs) doesn't need static parsing. What I need is a way to leverage the existing infrastructure in the interpreter for parsing in a way that's compatible with most modules/usages. AFAIK the parser in perl goes directly from source to an OP tree (modulo running other Perl code on the go that modifies the parsing state, which is the reason for the undecidability), it would be cool if it didn't go to an OP tree but something more AST instead, but it might not be feasible to change perl to do that because of modules working on the op tree (if anyone wants to help figure out how much this is true, please do); because of that I'll instead look into converting the op tree into an AST. I've been told the op tree does have additional info that might make that feasible. Notabene, B::Deparse exists, which is somewhat of a proof that this works, although there are limitations, whether they matter is part of what I need to find out.
- lloeki 7y ago
  Haha, my comment was definitely tongue in cheek ;) I fully expect most of properly written Perl code to be statically parseable into an AST, save for pathological cases (and I fully expect a proper rubocop-like Perl linter to highlight such ambiguities, and would reject them in any sensible project)