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 25 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • You are working under the assumption that you won't be able to reuse the existing toolchain to write these tools.

    The approach that everyone seem to be aiming for is that instead of writing PPI all over again for Perl 6, you are supposed to get decent enough support form the actual grammar that ships with the compiler in order to do your own interesting things with it.

    Secondly, since Perl 6 supports separate compilation units in many ways this is actually much simpler than Perl 5 - there is no more possibili

    • in the absense of any BEGIN { } declarations or importing of macros/grammars from other compilation units (this is something you can statically check for if the unit is already compiled)


      I am probably being thick, but once they code is compiled, haven't you already run the BEGIN block and all its arbitrary contents?
      --
      rjbs
      • The begin block itself has to be fully parsed before it's run.

        Similarly a macro or grammar extension coming from another compilation unit has already been compiled.

        At this point you can examine their code in a manner much like Safe does (existing problems in safe are an implementation issue, not a conceptual one), and run the code with some resource limitation if necessary (if this wasn't possible then we wouldn't have javascript ;-)

        Furthermore, if you deduced by static analysis that these blocks cannot aff
        • > At this point you can examine their code in a manner much like Safe does (existing problems in safe are an implementation issue, not a conceptual one), and run the code with some resource limitation if necessary (if this wasn't possible then we wouldn't have javascript ;-)

          You don't need to run Javascript in order to parse it, since it has (I think) a static syntax.

          Also, this comes down to practicality.

          "What percentage of CPAN can this parsing strategy handle?"

          As a context-free document parser, PPI can
          • With respect to dependencies that will indeed fail to work, but for use Foo that's untrue - Perl 6's importing semantics will support real linkage of symbols for the benefit of compilation units. The method 'import' and glob assignments are not supposed to be the only way to actually import symbols anymore. This solves a lot of issues.

            As for reading files etc in BEGIN - that's also handled differently - there is no guarantee that a BEGIN block will run every single time you run the program, it is fair game
    • > In other cases, if it's safety you're after, in not running the compile time code, then theoretically you just use something like perl 5's Safe on all the macros and grammar extensions.

      Only if you can solve the Halting Problem.

      In Perl 5, even trivial Perl examples involve BEGIN blocks (use strict) and grammar modification (operator/operand switching).

      This problem applies to Perl 5 to.

      Simon Cozens has a never-released parser based on the Perl internal parser.

      It works just fine, as long as the code compi

      • Only if you can solve the Halting Problem.

        No version of the Perl compiler or processor for any version of the language attempts to solve the Halting Problem. They tend to do a pretty good job on most reasonably correct code (and plenty of unreasonably incorrect) code as well. You don't need to solve the Halting Problem. You only need to decide if it's worth it at any particular point to Halt and say "Sorry, I'm not going to continue processing from here," and you can do that if you control the runloo

      • The halting problem only applies to code you cannot introspect.

        If you have a function, and that's all, then you can't find out what's in it.

        But given a compiled optree, you have much more information.

        If you parse the BEGIN { } block under the current rules, then you wind up with an optree which you can then examine, to see what it does.

        As for simon's project - perl 5's parser was never designed to make this easy, it was designed to emit an interpreter optimized optree. This is very different from the design
        • We probably need to escalate this to a formally trained mathematician here, but as I understand it, it applies to any case with "arbitrary" code whether introspectable or not.

          You CAN prove something will finish in finite time, you just can't prove how long that finite time is, which may be longer than the heat death of the universe.
  • The mutable Perl 6 grammar scares me too, but I'm hoping that people never use it and it doesn't become a problem.

    In my "Bird's Eye View of Perl", the talk I give to managers, I talk about Perl being a single language that comes from the same source. The idea of multiple implementations looks good on paper, but it doesn't work out in practice. Besides knowing the core language and its libraries, now the mere mortal users have to wrestle with pecularities of each implementation and grammar. It the reason I s
    • The mutable Perl 6 grammar scares me too, but I'm hoping that people never use it and it doesn't become a problem.

      Yet, whenever I raise my biggest objection I have against Perl6 (meaningful whitespace), I always get thrown back "well, you can change the grammar you know...".

      • Yeah, I was just going to say that. "Just change the grammar" was used to end Perl 6 language debate sort of like "God works in mysterious ways" is used to end religious debate.

        Thankfully I haven't seen it come up as much lately. Maybe folks are starting to realize that easily mutable grammars are a powerful and awesome tool but not the sort of thing you want every kid on the block to use.
    • I see multiple implementations as a strength.

      At some point you simply HAVE to be able to have an IronPerl6 and JPerl6 simply for long term language flexibility and health.
      • I thought that was the point of parrot---you didn't need different implementations if you had the byte code.

        I don't see different implementations as necessary to anything. Some people might like it, but in reality people will code to the implementation's features. It happens in Java, Javascript, Lisp, Smalltalk, and probably a lot of others that I haven't used. The conversations at the pub are about who supports what and what you have to do to make good code on one implementation work on another.

        It's not so
          • Catalyst dealt with the Class::DBI disaster by using something different. That's not how I want people to deal with Perl. :)
  • Seems to me the trick is to separate grammar changes from BEGIN blocks. That is, you have explicit blocks which do nothing but change the grammar. They can't execute code, they can't call eval, they can't declare variables, they can't load modules (except other grammar-only modules). They would then allow two critical things for tools:

    1) They're safe to execute.
    2) The tools can be made aware of grammar changes.

    It might not even need to be as restrictive as all that, maybe just that grammar changes happ
    • The problem is that the grammar is code itself.
      • That may not be a problem if the code is never run...

        If "=" is mapped to sub equals, you shouldn't need to run equals while parsing, right?
        • You don't understand. The grammar itself is a class. The parsing primitives are methods. It is actual Perl 6 code that does the parsing, you don't get a BNF for it.
  • 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"

  • Actually, because Perl 6 does have a grammar, a tool could include it's own parser which would could lex the code including any grammar changes without doing any of the calls which don't change the language. That wasn't really possible when filters were reaching in and twisting about the compiler innards. Consequently, tools like vim with it's own syntax coloring language which is not dynamic, will be less useful :( while others with plug-in token labelers will flourish -- well until someone replaces the cu
    • You've outlined the situation perfectly.

      Perl 6 breaks a ton of existing tools, while relying on the existance of new tools which everybody assumes will exist but nobody has actually proven can be written.

      • Perl 6 breaks a ton of existing tools,

        Besides the fact that the existing tools were written before Perl 6, there is no guarantee they would work with Perl 6 if grammar modifications were disabled. There is no existing tool today that works with perl 6 (other than basic syntax highlighting of various editors). Your entire basis in this thread is about the creation of "new tools which everybody assumes will exist but nobody has actually proven can be written.

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