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.

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 }
[download]

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.

-- Randal L. Schwartz, Perl hacker

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.

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";
}
[download]

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

foo "foo";
[download]

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";
[download]

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