How could Perl know this in the face of AUTOLOAD, run-time module loading, and symbol table manipulation?

The best I can see it doing is trying to resolve subroutine calls as they happen and throwing errors if it can't find them.

(I think your code has a bareword problem that makes it give an ambiguous error message, but that's just a guess looking at the snippet and not its context.)

How could Perl know this in the face of AUTOLOAD, run-time module loading, and symbol table manipulation?

It wouldn't be foolproof, but could the warning be somewhat like the "Name %s used only once" warnings with package variables? Example included for those who don't know what I'm talking about:

$ perl -wle '$foo = 1; print 5'
Name "main::foo" used only once: possible typo at -e line 1.
5
[download]

Not to mention even $obj->$method( ) or $methref = $obj->can( "kwyjibo" ).

A warning for subs that you declare but then don't use would be really annoying for those who are doing more advanced things behind-the-scenes. I might want to declare a subroutine name, but then define it at run-time.

In this case you declared two different subroutines names and only happened to use one. However, perl can't know that you are only going to use one until you are completely done with the program.

I don't run into this problem because I like parens that give perl a bit of extra help with the parsing (and keep maintenance programmers from getting too confused too).

chk_timer( $_ ) for ...;
[download]

But then your argument is just as valid for the annoying warning about a possible typo when using a package variable only once. Who says, I don't do advanced things behind-the-scenes then?

So if Perl warns me in this case, why not when declaring and failing to define a subroutine?

Paul

I don't like that "variable used once" either. If I've declared a variable so that use strict doesn't complain, but I only use it once, I don't want to see a warning. I've seen a lot of code that uses a variable in void context just to get around that warning.

--
brian d foy <brian@stonehenge.com>

A warning for subs that you declare but then don't use would be really annoying for those who are doing more advanced things behind-the-scenes. I might want to declare a subroutine name, but then define it at run-time.

Indeed in the very same script I had

sub killp;

*killp = DEBUG ? \&_killp_debug : \&_killp_real;
[download]

although I bet that many Perl hackers wouldn't regard this as a good practice.

However we already do e.g.

no strict 'refs';
# and
no warnings 'uninitialized';
[download]

all the time. A 'used only once' warning as suggested by someone else wouldn't be that bad after all.

I don't run into this problem because I like parens that give perl a bit of extra help with the parsing (and keep maintenance programmers from getting too confused too).

Well, that's to a very large extent a matter of personal preferences, just like so many other things in Perl. I find code having as few parentheses as possible to be best readable.

I find code having as few parentheses as possible to be best readable.

Depends. There are some situations where parens add clarity, and there are others where they don't. Generally speaking, if there's a significant potential for someone's not having memorized the precedence table to result in confusion, it's better to include the parens, but otherwise you can leave them off. Obviously, different people have different threshholds for how divergent the precedences in question have to be before the potential to misread is sufficiently small to justify leaving off the parens, but I think in principle most of us can agree that there are some pairs of operations with a very similar precedence, in which case the parens add clarity, but there are other pairs of operators that have such markedly different precedence that any clarity the parens add is extremely marginal and not worth the tradeoff. It becomes a question, then, of where to draw the line.

A good example of the latter scenerio is when you're using the loose-binding spelled-out logical ops to join together expressions containing tightly-bound operators, as in $foo .= <BAR> or return $foo;. Nobody with significant Perl experience needs parens to help them through that one. On the other end of the scale you can have expressions that include bitwise operators and other relatively obscure ops for which many people don't remember the precedence. In those cases, the parens are a Good Idea.

---

"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."  — Pratico & Van Pelt, BBHG, p68

I don't know much about how this kind of thing would be implemented, so I don't know whether it's feasible or not. But I just wanted to put my voice out there as agreeing to this. I think it would be a good idea, if at all possible.

You say there might be people who complain because they want to do symbol table manipulation, or similar things. Well, they can just turn off that warning. :-) People who are used to doing fancy things are already accustomed to turning off warnings and stricture when they need to. I can't see how this would be a major problem for them.

Run this:

#use strict;
use warnings;

sub bar {
    print $foo;
}

my $foo = 1;
foo();
bar();

sub foo {
    print $foo;
}
[download]

Now uncomment out the use strict; and run it. FWIW, i do the same as you ... but yes, there are consequences.

jeffa

L-LL-L--L-LL-L--L-LL-L--
-R--R-RR-R--R-RR-R--R-RR
B--B--B--B--B--B--B--B--
H---H---H---H---H---H---
(the triplet paradiddle with high-hat)

Maybe I'm a little slow, but are you and I talking about two different things? As far as I can tell, your bar routine depends on the global variable $foo which doesn't exist when bar is defined. What I was talking about was the need (or lack thereof) to put a superfluous declaration of all user-defined subs at the beginning of the file.

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

If the sub isn't declared or defined before use, then you can't call it like a builtin - without & and parentheses around the arguments. That's the main disadvantage for me.
chas

If the sub isn't declared or defined before use, then you can't call it like a builtin - without & and parentheses around the arguments. That's the main disadvantage for me.

Huh?!? You're joking? Indeed I do declare my subs to be able to call them without parentheses - fair enough. But it is never stressed enough that in Perl5 (as opposed to Perl4 and previous versions) the &-form of of sub call should never ever be used unless you really need it, i.e. you do know what you're doing. See perlsub.

Fair enough. But, now I'm curious. Since Perl doesn't have type checking, what good does declaring the subroutine get you? Why is perl not able to parse the file, say "hey, chas has subroutines foo, bar, and baz, so if I see them referenced, I'll use them"? Just seems odd to me.

thor

Feel the white light, the light within
Be your own disciple, fan the sparks of will
For all of us waiting, your kingdom will come

It is for the sake of C compatibility that there is no such warning:)