3 ms·
I don't think so. It is an example of how Perl's interpreter changes what a program means, based on information gathered at runtime. The halting problem stuff i
by neilk 17y ago
I don't think so. It is an example of how Perl's interpreter changes what a program means, based on information gathered at runtime. The halting problem stuff is just a formalization of the difficulty, to show that in some cases it's actually impossible to parse.
Try this one:
#!/usr/bin/perl
BEGIN {
my $x = int(rand(2));
print "randomly picked $x\n";
if ($x) {
eval '
sub foo($) {
print "executed foo()\n";
}
';
}
}
foo / 25; #/ ; die "DIED\n";
print "DID NOT DIE\n";
This is technically parseable but only by thinking of it as a program that branches at every call of 'foo'. And think about what would happen if many such cases interacted.
"Modern" Perl programmers use a lot of syntax-perverting trickery, so this isn't as unlikely as it may appear.
- nothingmuch 17y agocan you please point to a real example of code like this? just because a pathological case is possible, doesn't mean that it's actually common, or even existent.
- scott_s 17y agoThat it's even possible is relevant - most programming languages can be parsed.
- nothingmuch 17y agoThere's nothing preventing symbol table modifications done by Perl modules at compile time to be reified into some sort of linkage unit, with which a parser could then statically parse the code. Similarly it's possible to prove that a certain block of code does nothing but link in such deterministic units, removing the nondeterminism of function prototypes. Most of the source code out there can be parsed statically without resorting to anything drastic. The semantics of this hypothetical Perl 5 variant do differ, but as a strict subset it will still properly most of the useful code out there.
- scott_s 17y agoThat's not the point. It is interesting, from a programming language theory perspective, that Perl 5 can not be parsed statically. The person who wrote the proof sketch cares very much about the practical implications of that theoretical result because he's writing Perl parsing libraries. Also, what you're describing is no longer static parsing.
- deleted 17y ago[deleted]
- draegtun 17y ago"Modern" Perl programmers use a lot of syntax-perverting trickery, so this isn't as unlikely as it may appear. "Modern" Perl programmer do the complete opposite! This code completely ignores all the best practices that "Modern" Perl programmers adhere to so its is very unlikely to appear anywhere but in places like Perlmonks, Reddit & Hacker News ;-)
- mst 17y agoActually, we tend to use a limited set of things that's designed to parse sanely. people using a 'sub ()' prototype for anything except a CONSTANT_NAME will be taken behind the bikeshed, shot, eviscerated, cremated, resurrected, shot again, and then told it's now their responsibility to project manage the repainting as penance.