It's fallacious because you need to know you will reach the code which can make the determination. And to know, in general, that you will reach that nullarity-determining code you've got to know the answer to the Halting Problem in every form it can take. Being able to determine the nullarity of a Perl function, given arbitrary Perl code, amounts to being able to fully predict the operation of a Turing machine.
Re^2: Perl is not Dynamically Parseable
Replies are listed 'Best First'.
Before returning to the subject of this thread, I'd like to point out that ikegami is one of the very best contributors to Perlmonks. The quality of his nodes is even higher than his experience ranking indicates. A monk once suggested that an efficient way to deepen your Perl knowledge is simply to go to the list of ikegami nodes, and read, read, read. I've done this several times, and I'm happy to pass the suggestion on.
I'm happy to revise my node so it explains things better.
You discuss "what is the prototype of a function after parsing" (that's knowable contrary to your claims) rather than "what will be the prototype of a function after parsing" (that's not knowable).
Or put differently, you talk about one instance of the parser when the problem is with differences in the output of different instances of the parser.
If there's a fallacy, it's assuming that the output of an instance of the parser will be the same as the output of another instance of the parser. That would be a very bad fallacy to make since that's the general hypothesis that needs proving or disproving.