Fair enough, you know Perl's behaviour a lot better than I do.

I can see ways of modifying the code towards, and possibly all the way to the behaviour that you would like to see, although I wouldn't like to do so at this point, as I have the level of functionality out of the current codebase that I wanted as a minimum ( excluding bugs ), not to mention that it would slow things down a lot, since I'm not going to write any C into the back end.

But let me add this. Even if the source isn't parsed "properly" in some cases, it may not need to be depending on what you want to do with it.

I have no illusions of taking perl source code and executing it ( "flying a plane" ). But as I have pointed out, there are other uses for perl source that may not need the same level of rigour.

Allow me to add some questions to this.

Does the perl interpreter record all whitespace and comments, the content after the __END__ signal, and other stuff in it's model of the code? All this extra padding is required so that once you have a complete model of the source, you can serialize it all the way back down to text, and come out with what you started with? I would like to be able to have a piece of code walk into the code tree, modify the code within, and then be able to write that code back out to a file.

Is it EVER possible to write a proper and full perl parser without using perl itself... The B modules demonstrate this. Even if you could get a proper parser, what about things like CGI.pm? Can you tell what methods the CGI module will have? At some point, you either have to draw the line, or you end up with perl itself. I choose to draw the line at reading MOST source code. My stardards will probably go up over time, as code is added around the edges that NEED the extra depth.

Finally, two last questions.

1. What were you planning on doing with a perl parser.
2. How slow are you prepared for it to be?