Stories
Slash Boxes
Comments
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.

Why Perl 6 scares the hell out of me 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
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 insigh
    • > 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 this stuff, and at the moment the default expectation of many people seems to be on me.

      > I think it would be great to be able to have parsers/editors/refactor-ers that can "statically" (whatever that means)

      "Static" essentially means "context-free". That is, you can treat an arbitrary Perl source code file as a document, and parse it without needing to also parse any other documents.

      > When time permits, or the problem requires it, or when I get bored I may try to modify the grammar to fit my need.

      And this is EXACTLY what worries me.

      If it is EAST to modify the grammar or worse becomes fashionable to do so, then we end up in a world of mess because an even smaller percentage of existing documents can be parsed.

      > And if the tools aren't capable of being extended, well, then I'd seek out new tools.

      This assumes that 1) Other tools exist 2) Such tools are possible to write at all.

      > 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.

      No. I don't want it to be impossible to extend the grammar.

      I see a lot of (theoreticaly at least) value in things like "use physics".

      What I do see is a giant shiny thing that people will INEVITABLY want to use despite the fact it will make your code impossible to work with in anything more complex than Notepad.

      So I want it to be HARD to modify the grammar.

      Or at least I want something that triggers flashing lights and air raid sirens that you need to toggle before you are allowed to modify the grammar.
      • 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.

          Prett

          • 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

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.