If I had to guess (and I am) it's because your error is being reported during parsing and sub foo {} hasn't been seen yet. So when foo; is encountered the parser has to make a guess at what sort of thing 'foo' is and you just didn't provide enough information.

Additions: Ok, now that it's tomorrow and I've had some sleep I'll add more to this short comment. Actually... reading the source comments is probably a better description than I can provide so I'll copy a bit from my 5.6.1 source. This is from the intuit_method() function which is at least one place where the compiler makes it's guesses as to what is a subroutine or not. Of course, reading these descriptions it quickly becomes apparent that this

S_intuit_method Does all the checking to disambiguate foo bar between foo(bar) and bar->foo. Returns 0 if not a method, otherwise FUNCMETH (bar->foo(args)) or METHOD (bar->foo args). First argument is the stuff after the first token, e.g. "bar".

• Not a method if bar is a filehandle.
• Not a method if foo is a subroutine prototyped to take a filehandle.
• Not a method if it's really "Foo $bar"
• Method if it's "foo $bar"
• Not a method if it's really "print foo $bar"
• Method if it's really "foo package::" (interpreted as package->foo)
• Not a method if bar is known to be a subroutne ("sub bar; foo bar")
• Not a method if bar is a filehandle or package, but is quoted with

But then I gather that intuit_method is only called for some of the potential method DWIMery. Further reading shows that it just gets uglier and uglier. What I quoted was probably the most straightforward portion.

Fun Fun Fun in the Fluffy Chair