I'm not completely happy with most documentation I see on "compile time" and "run time". They mostly encourage or at least don't discourage the impression that there is one time called "compile time" when your script is compiled and then there is one "run time".

In reality, each statement has its own "compile time" and any number of "run time"s.

I find it clearer and more accurate to think about more detailed steps that perl goes through, in order.

1. Reads the next line of source code.
2. Compiles the next complete statement (if there is one)
3. Performs any "compile-time" actions for that statement
4. Go to (2) if there are more complete statements already read
5. Go to (1) if there are more lines to be read from the current source file
6. Run INIT blocks from the current source file
7. If the current source file is the main script, then run all CHECK blocks
8. Start running at the first statement (of the current source file) that is not part of a subroutine
9. Continue running until "falling off the end" of the current source file
10. Go to (1) on the previous source file if there is one

So, if I use require in my main script, then there can be whole files of Perl code that don't get compiled until after my main script has finished being compiled and has started running (and the require statement might not even get run).

Conversely, if I use that same require statement inside of a module that my main script uses, then those files will be compiled and their non-subroutine statements run before most of my main script is even compiled.

Update: s/of/off/. Thanks, gam3.

A compile time error is one the keep perl from being able to parse the file; such as a missing semi-colon. And a run time error is an error that can not be detected untill the code is run; such as a divide by zero error or a call to an undefined subroutine.

The Perl "interpreter" "compiles" your Perl script before "running" it. This happens in a number of phases with stuff in BEGIN blocks being processed first, INIT block code is processed following compilation, then the main code is executed then, at exit time, the stuff in END blocks. require statements are processed at run time, but use statements are processed before any other main code statements.

Note that the location of a use statement doesn't alter when it is processed, only their order in the file affects the order that use statements are processed. In particular, you can not prevent a use statement from being processed by putting it inside an if, it is processed regardless.

The complete story is more complicated, since Perl can also compile code on the fly even after the run phase has started (and can run code before the compile phase has completed). This is truly powerful, but difficult to wrap your head around.

The complete story is more complicated still, as perl is able to dynamically link to "Perl" libraries compiled from other languages, including C and C++.

But this is an aside. The problem in Perl is that certain operations can only be parsed completely in the run-time context.

Consider the following, for which C has no analog (buffer overflows notwithstanding).

 my $str = $ARGV[0];
 eval("use $str;");
[download]

Now, some theorists will complain bitterly that this must slow your code down, but this is usually the least of your problems. (See Optimising Perl.. for example)

Thog.

--
Dorothy Sayers is still correct.

"Consider the following, for which C has no analog"

In that particular case, dlopen does provide an analog. In fact, sufficiently devious use of system() and dlopen() and friends can do what eval does. (Not that I would recommend this.)