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
      • 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" as some kind of magic cure-all.
        Sure I can. If I write standard perl 6, then I can use the standard grammar and get a parsed tree back... Like magic... Just like I said in my first post. If I don't write standard perl 6 then all bets are off, just like I said in my first post.

        ...at the moment the default expectation of many people seems to be on me.
        Um, no. The standard grammar parses standard perl 6. I don't really expect anything of you. I don't intend this as a slight. I just really don't have any requirements placed on you.

        you can treat an arbitrary Perl source code file as a document, and parse it without needing to also parse any other documents.
        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 can't do it. You couldn't do it in Perl 5. You can't do it in Perl 6. If you allow inclusion of other documents, more things become possible.

        If all you want is to syntax highlight, then you don't need a parsed document at all. You are actually better off without having to parse the document as it is nice to have syntax highlighting while you are creating an as of yet uncompilable document. The last thing I want is for the syntax highlighting to disappear and reappear while I type because the syntax goes in and out of being correct and incorrect.

        > 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.
        This was my fault for stating or implying that I need these tools. I don't. My emacs highlights perl 6 documents just fine as it is RIGHT NOW. It even completes methods for me too, albeit in a non-class-associative way. I'm productive enough right now in Perl 5 and I'll be productive enough in Perl 6. I'm not sure why not having a parsed document forces us down to the level of notepad. Of course having PPI style tools could possibly help me be more productive - but there is no guarantee that they would even if the grammar was static.

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

        ...So I want it to be HARD to modify the grammar...
        To summarize with a run-on sentence: You want it to be difficult for an unquantifiable future developers, to potentially modify an un-finalized grammar, for an un-finished language, because the developers might possibly extend the grammar in a way that might possibly be harder to parse than the as yet-un-finished standard grammar, that might not be possible to statically parse, by a tool that doesn't yet exist, that hasn't been requested or at very least isn't required by the community and may or may not have any real utility at all, because writing the tool was barely possible for Perl 5, and writing the tool would be hard if not impossible for you to do.

        To sum up my summarization: You want to cripple Perl 6 because it might be hard for your non-existing tool to parse it.

        I think it should be easy to change the grammar. I'm glad Larry does too. I think amazing things will come of the ability to do so. I think it is premature to think that hobbling Perl 6 will provide more benefit than allowing for new design ideas. Nobody knew what would happen with CPAN when it was introduced. Modifyable grammars may fall on their face but I wouldn't bet on it.
        • > 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.