Bare Subnames

That bit about bare subnames made me question my thoughts on the subject, so I whipped up a little test:

#!/usr/bin/perl -w
use strict;

fight;
win;

sub fight {
    print "Fighting!\n";
}

sub win {
    print "Winning!\n";
}
[download]

Compile time errors about barewords. Now move the sub definitions up:

#!/usr/bin/perl -w
use strict;

sub fight {
    print "Fighting!\n";
}

sub win {
    print "Winning!\n";
}

fight;
win;
[download]

Works fine. One more try:

#!/usr/bin/perl -w
use strict;

use subs qw ( fight win );

fight;
win;

sub fight {
    print "Fighting!\n";
}
sub win {
    print "Winning!\n";
}
[download]

There. While I definitely recommend putting the braces () on the end of any subroutine name for the sake of code clarity, if a bareword can be resolved to a known subroutine name, whether defined in your package or imported via use or require or eval, the compiler won't throw an error. That's probably more specific than anyone wants to know, though.

Update: Yes, because require and eval work at run-time (not compile time), they need to be in a BEGIN block. Sorry for being unclear.

Comment on Bare Subnames Select or Download Code

Replies are listed 'Best First'.
RE: Bare Subnames by tilly (Archbishop) on Aug 10, 2000 at 15:33 UTC
I don't think that require or eval will cut it. What is going on is that Perl will not complain if it has already compiled the fact that you have subroutines when you hit the bareword. Since strict creates a compile time complaint, it will fail without ever paying any attention to require or eval. (Unless, of course they are in a BEGIN block.) This actually gets at some important points. The same behaviour that you see with strict comes up again with prototypes. Here is the underlying cause. When perl (not a typo, the language is Perl, the interpreter is perl) sees your script it fundamentally has 2 different things that it does. The first is it compiles code to an internal representation, the second is that it runs that internal representation. These take place in separate passes. However some things will cause it to switch from one to the other. While compiling if Perl sees certain things, for instance a complete BEGIN block or use, it will switch out of compiling your script to go do something else and then return to your script when it is done that. Conversely while running if your program encounters other things, for instance require and eval, it may have to go back to compiling more code. Now the (obvious) rule is that at no point can you take into account code that you have not (yet) compiled. By the time your main script gets around to running, most stuff has compiled, and it just works. But if the code affects compilation in some way (eg telling Perl that a sub really exists, or declaring a prototype for a subroutine) then it cannot take effect until after Perl has seen that text. Does that make sense?	[reply]

Replies are listed 'Best First'.

RE: Bare Subnames
by tilly (Archbishop) on Aug 10, 2000 at 15:33 UTC

require

eval

What is going on is that Perl will not complain if it has already compiled the fact that you have subroutines when you hit the bareword. Since strict creates a compile time complaint, it will fail without ever paying any attention to require or eval. (Unless, of course they are in a BEGIN block.)

This actually gets at some important points. The same behaviour that you see with strict comes up again with prototypes. Here is the underlying cause.

When perl (not a typo, the language is Perl, the interpreter is perl) sees your script it fundamentally has 2 different things that it does. The first is it compiles code to an internal representation, the second is that it runs that internal representation. These take place in separate passes. However some things will cause it to switch from one to the other.

While compiling if Perl sees certain things, for instance a complete BEGIN block or use, it will switch out of compiling your script to go do something else and then return to your script when it is done that. Conversely while running if your program encounters other things, for instance require and eval, it may have to go back to compiling more code.

Now the (obvious) rule is that at no point can you take into account code that you have not (yet) compiled. By the time your main script gets around to running, most stuff has compiled, and it just works. But if the code affects compilation in some way (eg telling Perl that a sub really exists, or declaring a prototype for a subroutine) then it cannot take effect until *after* Perl has seen that text.

Does that make sense?

[reply]