in reply to Re (tilly) 4: Appropriate CPAN namespace for perl parser
in thread Appropriate CPAN namespace for perl parser

I agree.

And this is my primary reason for thinking that a "guessy" perl parser would be enough. You eventually reach the point where you are loading a perl interpreter, firing up B:: to do a bunch of analysis, and then start a perl parsing process. I'm not convinced it can EVER be fully done.

And I'm starting to think it more as this thread goes on...

It also brings up questions like how to parse Win32:: code on a Unix box...? How could you parse any arbitrary piece of code without having everything it lists as a requirement installed, or at least on the machine

What if you are using some form of run-time module loading...
  • Comment on Re: Re (tilly) 4: Appropriate CPAN namespace for perl parser

Replies are listed 'Best First'.
Re (tilly) 6: Appropriate CPAN namespace for perl parser
by tilly (Archbishop) on Feb 13, 2002 at 16:47 UTC
    The issue of how to account for the effects of execution of code done at compile time is a deep one, with serious consequences for parsing Perl, compiling it, etc. The decision to allow that functionality imposes implicit limitations on Perl.

    However my thinking is that since these techniques are becoming more widely used on CPAN, support for doing them are moving into Perl's core, and the plans for Perl 6 are to improve Perl's support for this kind of functionality, I think that trying to ignore this issue is not wise, and will become increasingly not wise as time goes on.

    The moral is that you can only get 2 out of 3 of the following desirable features:

    1. Easy external parsing and manipulation of code.
    2. Support for macros.
    3. Syntactic sugar.
    Lisp has 1 and 2. TCL 1 and 3. Perl is in the process of adding 2 to 3.
[reply]

In Section Seekers of Perl Wisdom