The OP has convincingly proving that it is undecidable to determine the prototype of a given sub in a given piece of code. The choice of problem is because (now this is an appeal to intuition, not a formal statement) however you define "parsing", determining the prototype of a sub is something that by all sensibilities should result from "parsing". (Update: the prototype of a sub can also be made to affect whether a "/" is interpreted by the compiler as a division operator or the start of a regex match). Elsewhere I listed the example of determining whether a module loads successfully or not (i.e., whether the module returns a true value) as another thing you might imagine as being an outcome of "parsing".

So I can see where the OP is coming from, but of course it is a bit moot if you reject the artificial distinction between parsing and execution in a language like Perl, which allows arbitrary execution to be freely mixed with "parsing" phases. When you rephrase it more realistically as (for instance) "the BEGIN phase of Perl is Turing-complete", the whole exercise is trivial and loses much of its shock value.

I did some studying on non-determinism.

An example of a non-deterministic algorithm is mergesort.

use sort '_mergesort';
my @sorted =
    sort { substr($a, 0, 1) cmp substr($b, 0, 1) }
    qw( foo bar baz );
[download]

It is guarantees that the results will the sorted, but the relative ordering of baz and bar is not specified. Therefore, mergesort is non-deterministic.

Let's see if we can replicate the same situation with the parser.

The goals of Perl's parser include the production of functions.

package Mod;

BEGIN {
    my ($sub) =
        map "sub { $_ }",
        join ' ',
        map "$_();",
        sort { substr($a, 0, 1) cmp substr($b, 0, 1) }
        qw( foo bar baz );
}

sub foo { print "$foo\n" };
sub bar { print "$bar\n" };
sub baz { print "$baz\n" };

1;
[download]

The parser produces a function that calls foo(), bar() and baz(), but the order in which the calls are organized is not specified. Therefore, the parser is non-deterministic.

I don't know what that means wrt Perl's parsability, since I don't know I don't know how that's defined.

You have pasted an algorithm that is flexible in the final result set. Perl never has any question about ordering of what to do next here. Any wiggle room for this program would be in the flexibility of the algorithm, but when it runs it runs as a DFA. Please keep reading about non-determinism. You will come across the fact that every NFA has an equivalent DFA. It's just how it is. The fact of machines is that they aren't random- ever- and there is zero non-determinism at any given time.

I thought you were saying perl was not parsable. Now you do not know how to define it. By definition, it can be parsed. It's just a lot of work.

The whole bit about the halting problem is this. You cannot write an algorithm to understand a program's output for all possible input without running it. Parsability involves being able to read perl code; I do not see how this person's project has spiraled into declarations that it cannot be parsed. What they should say is, you cannot be a fortune teller of the output of such a program, and we all know that. Any language has that feature. It is neither mystical, magical, nor special to perl, and I believe this statement reinforces the commonly held belief that perl is hard to read.

Parsability involves being able to read perl code;

Parsing is the activity of assigning meaning to code. And since it's impossible to predict the meaning Perl will assign to code in some circumstances, the parser is non-determinisitc.

Even if you don't buy the conclusion, it's the premise that's interesting, and the problem faced by those who recently posted on p5p (if that's the project to which you were referring).

I'll have to get back to you on the first paragraph. The 5 minutes I have aren't enough

Please keep reading about non-determinism.

Any suggested reference?

I thought you were saying perl was not parsable.

I never said that. I know that Perl cannot be parsed without executing arbitrary Perl code, but I never even said that I believed that. I just answered your questions.

To say something cannot be 'parsed'

We're actually saying "It cannot be parsed without executing arbitrary Perl code".

Are you saying that's not the case? I have no idea what your first paragraph means.

My paragraph addresses unparsability. I'm guessing you agree in some way, as you are now qualifying the statement. I'd need you to expand on "executing arbitrary Perl code" to answer whether or not it applies to what I wrote.

I'm guessing you agree in some way,

Hold on. Not understanding something does not imply agreement.

All I did was to state the problem which was of interest to us.

I'd need you to expand on "executing arbitrary Perl code"

I'm not sure what you're looking for, so I hope the following helps:

To determine the meaning of a token, the parser needs to be able to execute any Perl program, including shelling out to execute any binary. The algorithms executed may be non-deterministic.