in reply to Appropriate CPAN namespace for perl parser


Several people have pointed out that "only perl can parse Perl".

This is an epigram, a play on words, a joke. It isn't an axiom unless we treat it as such.

Perltidy parses perl well enough for most peoples requirements. Also, Damian Conway has stated many times that he wants to parse Perl in Perl. As far as I've seen he doesn't get this type of reaction.

Adam's goal of parsing 99.9% of Perl, or at least the Perl on CPAN, is worthy and possibly obtainable. He appears to be aware of the difficulties. As such we such lend support rather than prejudging it. A tool such as this would be extremely useful. The CPANTS project, for instance, is probably doomed without something like this.

--
John.

  • Comment on Re: Appropriate CPAN namespace for perl parser

Replies are listed 'Best First'.
Re: Re: Appropriate CPAN namespace for perl parser
by demerphq (Chancellor) on Feb 13, 2002 at 13:27 UTC
    Im glad you mentioned Perltidy. In many respects perltidy already contains a tokenizer that handles the majority of perl constructs, as well as mechanisms for identifying some of the more pain in the ass errors (such as a missing { ( [ Also there are tools such as B::Deparse that would probably help with the task of resolving (semi)ambiguous statements (otoh that might not be the best plan for security reasons... :-)

    Much respect to adamk for trying a hard task, but I would hope he at least has a look at the existing codebase and would prefer that he joins forces with those authors. At the very least it would make a very popular tool like Perltidy even better...

    my $.02;

    Yves / DeMerphq
    --
    When to use Prototypes?