#!/usr/bin/perl -wT

     my ($global_vars....) = (global_var_definitions);
     # : Continues for some time

     sub func1 {}
     sub func2 { calls FuncN(), for example }
     # : many functions

     my (%funcN_data) = ( stuff );

     sub funcN { reference to %funcN_data fails silently }
[download]

I think your pseudo-defined complaint is more a matter of your having poor expectations, rather than Perl doing something unreasonable. What would your expectation be of this code?

my $foo;
print_foo();
$foo = "Hello\n";
print_foo();

sub print_foo {print $foo;}
[download]

The first call shouldn't see the initialization because the straight-line code has a function call before my has been defined, and one after. Now should it matter where my is? How about these?

my %data = default_data();

sub whatever {
  my $self = shift;
  # ...
}
[download]

When Perl first sees those it may not be able to even attempt to do the assignment.

Perl uses a very simple rule. There is stuff that it takes care of when it parses and compiles the file, and there is stuff that it takes care of when it executes. Figuring out what function to call and what variable is which is part of parsing and compiling. Actually doing things with those variables (like assignment and function calls) are taken care of at executation, which means that they have available to them other things that have happened already while executing, and the definitions of everything in your code.

What it also means is that function calls don't see assigments that haven't happened already. In other words Perl does actions in the order it sees them. Not very surprising at all when you think about it like that!

Now for your problem there are two obvious solutions. One is to move the functions and private data into its own module. Now you load and initialize that data in one obvious step. The other is to memoize your data lazily like this:

{
  my %private_stuff;
  sub some_func {
    unless (%private_stuff) {
      %private_stuff = qw(some defaults);
    }
    # ...
  }
}
[download]

This is something that tye and I have disagreed on for a bit. Personally I never use BEGIN in the way that he does, and I have yet to find a situation where I didn't find the above two solutions sufficient.

Is %funcN_data something that needs to be declared and kept as information in the main block? Is another function besides funcN going to need that information? If so, it's global data, you should declare it right away. Otherwise, it can be made lexical to funcN by putting the  my (%funcN_Data) = (stuff); inside the sub {}'s. If the data in that hash is persistent, this looks like an excellent case for using package and bless-- and now you're into OO Perl, which will probably feel familiar to someone coming from a C++ background.

Perl lacks a great way to declare static variables.

sub routine {
    my $static if 0;
    $static= 'value'   if  ! defined $static;
    # ...
}
[download]

is the closest you can come and that (once you think about it enough) makes my solution look downright tasty. (:
        - tye (but my friends call me "Tye")