SPUG:Can perl parse Perl?

[Michael R. Wolf]

Geoffrey & Kristin Grosenbach <glyph at mac.com> writes:

> It is downright embarrassing that Perl claims to be the mother of
> all parsing languages, and yet cannot come up with a decent way to
> parse it's own code (yes, I know this is part of the purpose of
> Perl6). I've worked with doxygen and JavaDoc, and I would greatly
> benefit from such a system for Perl. In fact, I was talking with Tim
> about this at Colin's party.
> 
> At minimum, it would be a script that would go through existing Perl
> code and build up POD sections for each function. At another level, it
> could look for function declarations and use those to make more
> thorough documentation.
>     This gets a little fuzzy since all we really have is
>     sub foo($$;\@)
> which most people never use. Damian mentioned a style that I use, namely
>     sub foo { my ($param1, $param2, @param3) = @_; }
> which would be fully sufficient for a parser.

I like the style, but recognize that any tool you build to extract
docs will be based on a *style*, not on the language, and therefore of
limited use (possibly only to you and your style-adopting collegues).
Ever try to get a style guide adopted?  Ever try to heard cats?

You state that it would "fully sufficient for a parser", but in fact,
it's only "fully sufficient for a well-integrated collection of trick
tools and ever-changing style guides".  Start down this path, and
you'll get impaled in a similar fashion to the folks that try to
"parse" HTML with RE's.

I therefore concur with your sentiment about not having a language
parser as a basic building block to build language support tools.

About a decade ago, I worked at a company that provided C language
CASE tools.  One perspective of why the company went belly-up is that
we died from the cost of writing our parsers and debuggers as building
blocks for the upper level tools.  We had started to make integrations
to existing tools (gcc and dbx), but by then, we'd already burned
through too much VC cash.

I'm looking forward to the kinds of auxiliary tools that a
parser-as-building-block will provide.  It'll effectively open the
source of this Open Source language!!!

 - class browsers
 - code analysis tools
 - impact analysis tools
 - class inheritance diagram builders
 - funciton call diagrams
 - cohesion/coupling analysis
 - metric analyzers (cyclic complexity, function points, LOC, etc.)
 - impact analysis for redesign or refactoring
 - refactoring editors (wouldn't Fowler and the Gang of Four be proud?)
 - lint(1)-like external programs to augment the venerable -w
 - style guide enforcement
 - keyword hilighting that *always* works
 - indent(1)-like programs that *always* work
 - ctag(1)-like interfaces that *always* work

Now you're starting to talk about a power environmenet and a healthy
ecosystem for many businesses and services.

    Perl, the language rules!
    Perl, the environment drools!

Actually, I'm not so simple-minded in my thinking as this trivial,
polarizing tag line would indicate, but it was kinda fun to put in as
a trailer.  :-)

You have to realize that I really do love Perl, and want the very best
for it.  I think that a Perl parser is the kind of enabling technology
that will provide that.

Michael

-- 
Michael R. Wolf
    All mammals learn by playing!
        MichaelRunningWolf at att.net