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 Alias (5735)

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

      by chromatic (983) on 2008.01.29 17:10 (#60653) Homepage Journal

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

      Now if it's possible to modify Perl 6's grammar lexically within Perl 6 programs by writing only Perl 6 code, then it follows that Perl 6 must be able to parse Perl 6 grammars and have a pretty good idea of what they do. The rules are fairly declarative, after all.

      I agree that it's likely possible for someone curious, malicious, or incompetent to write a grammar in such a way that you can't predict the effects of things (storing grammar rules in an eval run conditionally thanks to rand for example), but I'm not sure anyone thinks that BEGIN { POSIX::_exit() if rand() < 0.5 }; is a smart thing to put in Perl 5 code either.

      Reply to This

      Parent

      • Re: (Score:1)

        by Alias (5735)

        This pretty much covers my point.
        
        If the code does anything remotely interesting or unusual, you have to abort parsing the document. (worse, you may have to do it after already having spent significant CPU trying).
        
        Limiting yourself to documents that compile significantly reduces the types of tools you can use.
        
        I guess in a way this entire post is something of a challenge to prove that a useful non-executing parser can be written for Perl 6.
        
        Maybe I should formalize it at some point.
        • Re: (Score:1)

          by chromatic (983)

          If the code does anything remotely interesting or unusual...

          ... and non-declarative, which I think you keep overlooking. While I agree that there are ways to write grammar actions that change parsing in unfortunate ways, grammars themselves look more or less statically decidable in ways that regular expressions aren't.

          I won't suggest that they're quite as static as an EBNF grammar is, but they're much, much closer than the Perl 5 parser. It should be possible to identify arity and precedence without
          • Re: (Score:1)

            by Alias (5735)

            Well, I'm assuming that "interesting an unusual" things will be non-declarative.
            
            Anything declarative becomes "normal" for Perl 6.
            
            Grammar changes have two overlapping issues.
            
            There's the BEGIN problem. Lets assume that isn't a problem because grammar changes are declarative and decidable.
            
            The secondary problem for grammar changes is how to (and if you can) handle syntactic and semantic modelling for the resulting document in such a way as to allow for stuff like $document->find('comments');