http://qs321.pair.com?node_id=790675


in reply to Re: Unparseability is A Good Thing
in thread Unparseability is A Good Thing

Yet another proof: 
BEGIN {
   my ($add_ts) = @ARGV;
   eval 'use subs qw( die )' if $add_ts;
}

sub die {
   my $ts = '[' . localtime() . '] ';
   my $msg = join '', @_;
   $msg =~ s/^/$ts/mg;
   CORE::die($msg);
}

die("foo\n");

[download]
>perl test.pl 1
[Sun Aug 23 11:52:55 2009] foo

>perl test.pl 0
foo

[download]

Execution is required to decide whether die is a subroutine call or an operator.

Replies are listed 'Best First'.
Re^3: Unparseability is A Good Thing
by Zen (Deacon) on Aug 26, 2009 at 19:51 UTC
    I don't agree with this one. An interpreted language can be parsed, by definition. To say something cannot be 'parsed' is to say the program itself is non-deterministic in its syntax (not its outcome).

    If I remember where this bandwagon came from, it was someone's project who realized the project was too hard to write perl to run perl. It was not proven that it cannot be done, however often touted.
[reply]
      I agree with you that the definition of "parsing" is not well-defined in the context of this thread. As I have mentioned elsewhere in the thread, in Perl the line between "parsing" and "execution" is fuzzy and in my opinion artificial. The distinction is influenced from the way other, more conventional programming languages are executed, which doesn't apply well to Perl.

      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.

      blokhead

[reply]

      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.

[reply]
[d/l]
[select]
        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.
[reply]

      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.

[reply]
        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.
[reply]

In Section Meditations