http://www.perlmonks.org?node_id=663459


in reply to Re: Perl Cannot Be Parsed: A Formal Proof
in thread Perl Cannot Be Parsed: A Formal Proof

In the sense I think you might mean, nothing should be done. I use Perl 5, I like Perl 5. I don't see a need to regard static unparsability as a problem and "solve" it. Larry apparently is going to static parsability in Perl 6. I don't have a firm opinion about whether that is bad or good. I do think that it's proved wise in the past to listen to Larry in these matters.

The reason for a proof is there had been considerable question about whether Perl 5 was statically unparsable just for practical purposes, or just given present parsing techniques. Adam Kennedy's PPI man page says that the module name Parse::Perl had been reserved in case someone invented a way to statically parse Perl. Opinion shifted to the point where the most people felt certain that no static parser for Perl existed. But I think it's nice to get the issue completely nailed down.

Lack of static parsability is an obstacle for many utilities that deal with Perl 5 code. That's definitely a downside. But it's not the whole equation, and the ability to do Turing-equivalent fiddling at BEGIN time is an upside.

  • Comment on Re^2: Perl Cannot Be Parsed: A Formal Proof

Replies are listed 'Best First'.
Re^3: Perl Cannot Be Parsed: A Formal Proof
by merlyn (Sage) on Jan 22, 2008 at 13:14 UTC
    Larry apparently is going to static parsability in Perl 6.
    You seem to be missing a "not" in that sentence.

    The last time I brought this up with Larry, which was admittedly a year ago, he wasn't going to budge on either of the dual-nature of "/" or the ability to prototype a subroutine to influence the number of parameters.

    Indeed, part of the difficulty in having implemented Perl 6 so far is not being able to have a clean lexical phase, thanks to this wonderful "perfect storm" of desirable features. You must execute Perl code at compile time, even in Perl 6, in order to even tokenize the remainder of the file.

    The only concession I heard from him is that the results of that executed code would not be promised to be carried forward into the result of the compilation, which seems a bit odd, as it would break things like:

    my $x; BEGIN { $x = time }
    Unless the BEGIN block is executed both at compile time and once at pre-run time.

    Of course, I might be a few months out of date. I got bored following all the Perl 6 stuff, so I'm working on Smalltalk for a while until Perl6 gets a bit closer to a release.

      Larry apparently is going to static parsability in Perl 6.

      You seem to be missing a "not" in that sentence.

      I personally believe a verb is missing as well, BTW.

      --
      If you can't understand the incipit, then please check the IPB Campaign.
Re^3: Perl Cannot Be Parsed: A Formal Proof
by moritz (Cardinal) on Jan 22, 2008 at 13:31 UTC
    Actually Perl 6 is even harder to (statically) parse than Perl 5, because it is much easier to change the syntax.

    You can, for example, introduce new operators very easily:

    multi sub prefix:<foo> (Str $a) { return $a eq "foo" ?? "bar" !! "foo"; }

    This will define an unary prefix operator that takes one string as an argument. When somebody writes

    foo "foo";

    You can't know if that's a method call or a call to an operator. You'd think it makes no difference - but wait until precedence comes into the play:

    BEGIN { eval " multi * prefix:<foo> (Str $a) is tighter(&infix:<~>) { return $a eq 'foo' ?? 'bar' !! 'foo'; "; } # and later in the code: foo "fo" ~ "o";

    If that foo parsed as a sub call the precedence is lower than that of the concatenation ~, and the other way round if it's parsed as an operator.

    This is quite a complicated example, but there are much easier ones with "real" macros. (But since no implemenation really implements macros by now, I don't really know much about them).