use Perl

• reusable toolchain? (Score:1)

  by nothingmuch (5848)

  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
  • Re: (Score:1)

    by rjbs (4671)

    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
    • Re:reusable toolchain? (Score:1)

      by nothingmuch (5848) on 2008.01.29 12:15 (#60639) Homepage Journal

      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 affect your code (Because, for instance, they never address the grammar classes, or they don't touch any symbol table, they never run string eval, etc) you can deduce that this code will not affect parsing in any way, and thus skip it entirely when you are only parsing (as opposed to compiling).
      
      On an unrelated note, another benefit of this extensible toolchain approach is that if you *do* implement a DSL, then any tool can at least still parse it properly, and if the DSL is very simple or the tool is easily extensible you can get the tool to treat this code correctly too.
      
      Imagine PPI being able to correctly parse Switch.pm's statements because Switch defines it's magic in terms of a real parser extension. It produces a new type of tree node that PPI using tools might not know how to handle, but they can at the very least safely ignore them. If the node does roles (like a 'ControlBlock' node for a Switch statement) then the tools might even be able to work with them anyway (like Perl::Tidy fixing parenthesis for Switch statements just like it would for if { }).

      Reply to This

      Parent

      • Re: (Score:1)

        by Alias (5735)

        > 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
        • Re: (Score:1)

          by nothingmuch (5848)

          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