Because there are more ways of creating a subroutine than just declaring it. Look up the documentation for AUTOLOAD, for starters.

In other words, it's a feature, not a bug. Or rather, it is a bug, but a particularly nice one.

----
I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident.
-- Schemer

Note: All code is untested, unless otherwise stated

Whilst your cow orker is correct that C wouldn't let you do that. It is also true that C won't let you create subs at runtime or autoload subs at runtime. That's not strictly true with dynamic libraries, but then C can't check whether they will be available to be autoloaded at runtime either, so that mirrors the situation in Perl.

This point is that any system that allows late binding of subroutines cannot check for their availability until runtime. The benefits of late binding are sufficiently worth while, that foregoing the benefit of static compile-time cross-checking is worth it.

If you really want full compile time checking, you could always copy the source of all the modules you use in each script directly into the script itself, and comment out the use Module::Name; lines. Each script would become enormous and maintainence would become a nightmare as you would need to edit every script that used a module every time that module was ungraded.

The choice is yours:)

Well, I'm sure someone else can explain better and more technically correct, but I imagine it must have to do with the fact that you can define subroutines in perl at runtime, via things like 'do', 'require', 'eval', so perl can't check at compile-time whether a certain function-call will be defined or not when it is called... says me: "C wouldn't let you do that!" (i.e. it's a feature!)

my $file = shift or die "USAGE: $0 [file]\n";
open CODE, $file or die "can't read $file: $!";
my $code = do {local $/;<CODE>};
eval $code;
warn $@ if $@;
[download]

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)

The problem with this is that if the undefined sub is in a branch that does not get executed in the envronment you have created, it will still not be caught.

if (0)
{
  undefined_sub(); # no error even at runtime
}
else
{
  undefined_sub2(); # error here
}
[download]

--Bob Niederman, http://bob-n.com

On top of the other points made here I thinks its worth pointing out that subs are essentially package variables that our() doesnt care about (it turns out there are quite a few of them *Globs are exempt from strict as are Fully::Qualified::Items and the punctuation and magic vars). And in fact the magic involved in your example (that of exporting subs) exploits this fact. Consider this

use strict;
*foo=sub{print "foo"};
foo();
[download]

Which is in fact very close to what that use Module qw(fubar); actually does behind the scenes. When perl sees use Module qw(fubar); it doesnt think to itself "they want to alias Module::fubar() to main::fubar()" or any such declaration. Instead perl just thinks "oh, they want to pass an argument to that funny looking subroutine that happens to be a file full of subroutines, including one called import() which is in fact where I shall pass those arguments" and once the arguments are passed to import(), what import() does with them is entirely up to it. As it happens normally the result is that a line like

  *"${pack}::${name}"=\&fubar;
[download]

Which is just an assignment that happens to set up the symbol table in such a way that it results in the appearance of the subroutine being "exported", which of course it isnt, it stays right where it is, and just pretends to be in both packages (if it was in fact a closure it would still be bound to the context inside the other module.)

Youll find that a lot of stuff in perl that has to do with package variables doesnt play quite as you might expect with strict, filehandles, formats etc.

    -- Chip Salzenberg, Free-Floating Agent of Chaos

I didn't see this mentioned yet, so I apologize if I just missed it...

You can program in a Perl style that detects mispelled subroutine names at compile-time. This requires that you pre-declare all of your subroutines¹ and then never use parens when you call subroutines.

This, of course, doesn't work for method names. Compile-time checking of method names is nearly antithetical to Perl 5's OO system. (:

¹ Well, you could probably instead topologically sort your subroutines, but I wouldn't recommend it.

Having puttered, I share:

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

use vars qw($boo);
$a = foo() if 0;

sub bar {}

END {
  no strict 'refs';
  my $table = '::';

 SYMBOL:
  for my $sym (sort {lc($a) cmp lc($b)} keys %{$table}) {
    next if $sym =~ /::$/ or $sym =~ /^[A-Z0-9]/;

    my $name = $table . $sym;
    next if $name =~ /^::\W/;

    foreach my $thing qw(ARRAY HASH IO) {
      if (defined *{$name}{$thing}) {
    next SYMBOL;
      }
    }
    print "Look at this!\n";
    unless (defined *{$name}{CODE}) {
      warn "Possible undefined routine '$sym'";
    }
  }
}
[download]

The problem is that *{$name}{CODE} is as expected, undef for symbol foo, and not undef for symbol bar, but it is also undef for symbol boo. That is, there's no way to distinguish at the symbol table level between an undefined subprogram name, and a scalar, because both will have

  defined(*foo{SCALAR}) && !defined(*foo{CODE})
[download]

Hmph.

--
Jeff Boes Database Engineer Nexcerpt, Inc.	vox 269.226.9550 ext 24 fax 269.349.9076  http://www.nexcerpt.com
...Nexcerpt...Connecting People With Expertise

I think this is a fantastic idea! I suspect that there is a way to distinguish these cases if someone dives a little deaper into the internals.

I'd never thought of this idea, but upon hearing it, it is such a good idea that I'd be a bit surprised if someone hasn't already tried this and perhaps succeeded (or figured out exactly why you can't do it).

Anyway, I'm very interested in seeing this tool become available. Please consider posting this as a new root node, especially if you don't get any useful responses in the next while.

Thanks much. I'm looking forward to being able to do:

    perl -MDevel::ShowUndefSubs -c myScript
[download]

                - tye

When I test it, it does not seem that END blocks run under -c. However a CHECK block will - and the line, return unless $^C; will properly make it only run if you are running under -c.

Also it is a horrible hack, but you can test for scalars that have been declared with vars by evaling a piece of code which switches to that package and tries to access that variable. You can also test if the variable itself has a value. This doesn't, unfortunately, catch variables initialized with our. (Well I don't like our so I don't consider it that unfortunate...) However it catches vars, and it catches the common case of modules that initialize @ISA, etc while declaring them with our. (You also clear out a couple of global variables in main:: which are used by Perl internally.)

If you turn this into a module then I would think carefully about how you want to control what will be checked for errors, allowing someone to readily decide that certain packages and functions are known to be OK, or only certain ones should be checked. After all the maximum utility will happen when you can check your code, see some errors, and then OK them as you figure out that they really are OK...

It is probably more fruitful to use the compiler backends (the B::* modules) than rely on the symbol table, or at least the symbol table alone.

Makeshifts last the longest.