in reply to Re: Appropriate CPAN namespace for perl parser
in thread Appropriate CPAN namespace for perl parser

I apologise for the lack of depth, as I don't have huge amounts of time on weekdays for posting.

When I started this, I decided from the very beginning that I would not be able to write a "parser" capable to actually executing code. As I was told on more than one occasion, "that was lies madness". But executing code is not the only thing that get's done with code. Syntax highlighting, perltidy, source code analysis and a few other functions can all benefit from the ability to lex source properly, even if it can't execute it. The parser is written with that limit in mind. If you don't have to execute the code, you can be a bit more lax with your standards. As long as you parse the source code correctly in 99.9% of cases, you can get value from it.

Second, to touch on the code structure, this is a char by char parser broken into two pieces. The first part Perl::Tokenizer:: goes over the code char by char and seperates the code into bits and returns a Perl::Document. The Perl::Lexer:: takes the document and builds the object tree, classifies blocks, and tags some extra information in about comments.

This leaves you with a Perl::Lexer::Tree. From there, other modules, such as Perl::Transform::Tidy operate on trees. In the case of Tidy, it hunts down the tree and removes all whitespace, and then inserts replacement whitespace. Once the tree is flattenned back into a Perl::Document, and serialised into plain text again, the payout should come out the way you want it ( The Tidy code is currently not good enough by far ).

Let me also note that this module is still considerred very experimental, although the syntax stuff works nicely. I expect to change module names, terminology, and possible method names before it is ready for CPAN.

I'll try to attach further comments directly to the other comments.
  • Comment on Re: Re: Appropriate CPAN namespace for perl parser