Slash Boxes
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
More | Login | Reply
Loading... please wait.
  • I'm afraid that I can't restate your concern without putting words in your mouth - so I won't try. So I will look at this from my own perspective.

    I think it would be great to be able to have parsers/editors/refactor-ers that can "statically" (whatever that means) analyze Perl 6 code and do neat(tm) things with the output. I will write the majority of my Perl 6+ code in the standard grammar using the future best practices for doing so because I think there will be great tools that will give great insight into my code. And I think that the standard grammar will make it much easier to do (much more easy than what Perl 5 gave which was nearly nothing). I see no reason why there can't be a standard PPI6 - it is just the standard grammar. Done.

    When time permits, or the problem requires it, or when I get bored I may try to modify the grammar to fit my need. Why would I ever assume that if I was writing a grammar modification - that some stock code analyzer would be able to read code written in my new grammar. That would be a foolish assumption to make. It would also be an error on my part to require that it must be able to parse my new dialect.

    Now - I assume that there will be those who will write nifty changes to the grammar. I don't know that they will, but I have every reason to assume that somebody will make a useful module that overrides the stock grammar. Why would I now assume that the stock code analyzer would be able to parse this new dialect. Again - it would be a foolish assumption to make. Again - it would be an error to require that the stock analyzer be able to parse the code. But in this case, if they have written a nifty extension to the grammar and it saw sufficient uptake and was widely popular, I would assume that somebody would write a plugin to the stock analyzer that would let the extended grammar parse just as well. And if not, and it was important to me, then i'd try and figure out how to do so. And if the tools aren't capable of being extended, well, then I'd seek out new tools.

    I don't mean to be argumentative, but I think the picture painted is far worse than what you have presented. Here's where I put words in your mouth ... you want "easy to parse," "standardized," "refactorable," syntax and you are scared that somebody will extend the grammar, so we shouldn't be able to extend the grammar. Well, all of that request will be available, except for the "shouldn't be able to" part. That part is replaced with "most of the time people won't, but sometimes they will, and if they do, then maybe it isn't all bad for them to."

    I think in the rare cases, this will be the fusion powered ultra mega swiss-army chainsaw of death that will make it possible to do the impossible job. Maybe even make it easy. And I won't care if I have to edit the code without the help of a stock analyzer. But most of the time I'll settle for using the ultra swiss-army chainsaw that is called Perl 6 - and will love using PPI6 enabled tools to do so.
    • > I see no reason why there can't be a standard PPI6 - it is just the standard grammar. Done.

      There is a VAST gap between anyone thinks is true and what they can prove.

      Personally I DO see reasons why, plenty. Because I spent three years wrestling with them in Perl 5's grammar, several of which are based on mathematically provable impossibilities. And these grammar problems remain in Perl 6 unchanged.

      You can't just invoke the "standard grammar" as some kind of magic cure-all.

      SOMEONE has to eventually write
      • I am fully aware of your work with PPI on Perl 5. I am aware of the "proof" that it is impossible to statically parse Perl 5. I think they are amazing accomplishments. That said, I haven't had any need for PPI on Perl 5 and I think that it is obvious that BEGIN blocks potentially make it impossible to parse Perl 5. I believe your zero-ary sub followed by regex issue is actually taken care of in Perl 6 - at least the standard parser will be able to handle it.

        You can't just invoke the "standard grammar"

        • > Like magic...

          There is no magic, just complexity we don't understand enough.

          > I just really don't have any requirements placed on you.

          I didn't say YOU, I said "many people". I seem to get those sorts of comments about once a week or so.

          And from about 50% of everyone that has used perlcritic or something else PPI-based.

          > If you want to refactor your code or have method autocompletion, or check the code for security problems it is an impossible dream to analyze the code as an isolated document.

          • You might be brilliant enough to productively work on 100,000 line projects written by other people with nothing more than emacs...

            All of my jobs to date have met this criteria. Most of the jobs have been "pure perl" shops with 3 to 20 perl developers. We are hiring now in Orem Utah if anybody is interested. And emacs and vim are still the best tools for the job where I work. Not to abuse perl critic - but it helps little in what we are doing, whereas test suites and Devel::Cover help considerably