A use Module will cause the module to be loaded when the program starts, regardless of where in the script you put it (it gets run in a BEGIN block).

I personally think it makes more sense to put all your "use" statements at the start of your script, that way you can easily see what your dependencies are - no nasty surprises.

I also like to put all the "use" statements at the top, with one exception, and i believe this is what OP is looking for:

use ModuleUsed::LoadedAt::CompileTime;
sub sub1 {
  require Module1;  # loaded at runtime
  ...
}
...
[download]

By using a require statement, the module will only be loaded at runtime of that line, which means IFF sub1() is called. The huge advantage here is that Module1 is only loaded into memory when (if ever) needed, which could be a big time/memory saver if it is a large module, especially if memory footprint is an issue.

If your modules where only used sometimes, i. e. not every sub is called always when your program runs, you could require them:

sub only_uses_sometimes {
  require My::Module;
  # and call import, if you want some exported things
}
[download]

Now the module will be loaded at run time.

--Frank

'use pragma' statements are different, for example, 'use integer' has block scope.

Update: (*) or package scope if applied within the scope of a package declaration.

'use module' statements have file scope.

They have package scope. Or rather, the require portion has program scope, the import portion has package scope.

package Foo;
use Benchmark qw{cmpthese};

package main;
cmpthese( -1, { ...etc... } );

__END__
Undefined subroutine &main::cmpthese called at - line 7.
[download]

update: It's worthwhile to add that import acting in package scope is conventional, not a rigid truth. import is free to do what it wants, but it is usually defined by Exporter (or like Exporter) to inject symbols into the caller's package scope.

That's a bit misleading. Benchmark::cmpthese will be available in your entire program - in both packages. And so will Foo::cmpthese, for that matter. "package scope" is a bit of a misnomer, as there isn't a place where a package end (unlike a lexical scope).

I like to compare the package statement to the effects of cd. And if you do:

    cd /Foo                          # package Foo;
    ln /Benchmark/cmpthese cmpthese  # use Benchmark qw{cmpthese};
    cd ~                             # package main;
    ./cmpthese                       # cmpthese();
[download]

you get "no such file or directory". But that doesn't mean the link /Foo/cmpthese has ceased to exist.
Perl --((8:>*

A module is loaded at compile time, no matter where you place the use Module (except in an eval STRING). A module cannot be 'unloaded', although those that specify an unimport may allow you to turn off any semantics that they export using no Module. If you want a module to be loaded only on first demand, you could require it instead.

I personally prefer to put all my use statements at the top of the file (so I know which modules my code needs to run in a single glance), although others may prefer to put them in the subroutines that actually need their functions/semantics.

I wasn't expecting this though:

use strict;
use warnings;
foo();
print Dumper [4,5,6];
sub foo
{
    use Data::Dumper;
    print Dumper [1,2,3];
}
print Dumper [7,8,9];
[download]

__CONDENSED_OUTPUT__
$VAR1 = [1,2,3];
print() on unopened filehandle Dumper at D:\perl\t.pl line 4.
$VAR1 = [7,8,9];
[download]

Why isn't the third print Dumper 'correctly misinterpreted'?

Why isn't the third print Dumper 'correctly misinterpreted'?

I'm not exactly sure, but it looks like perl makes the decision whether that's a filehandle or a function call at compile time, and it doesn't make that decision properly until the symbols are actually loaded (which happens when the use line is reached). And since this is all compile-time behavior, the fact that use is wrapped in an implicit BEGIN block doesn't come into play yet.