in reply to Re^5: perl language
in thread perl language

There's another reason why this path is not really worth taking. There is no clear and set "compile time" and "execution time" with Perl. When you start a Perl program it's not first all compiled, including all modules, but instead a bit is compiled from the script, a bit from the module it uses, a bit from the module that module uses, then the code that's outside subroutines in that second module gets executed, then the import() subroutine of that module gets executed (if present), then perl returns to compiling the first module, compiles&executes some more modules, finaly finishes compiling the module, executes it's top-level code and import(), compiles a bit from the script ....

And I did not even mention BEGIN{} blocks that are executed as soon as fully compiled, before the stuff that follows gets compiled.

And the already compiled and/or executed code can affect how is compiled (even parsed!) the rest of the code:

V:\>perl -MO=Deparse -e "$x = FOO + 7 + 9" $x = 'FOO' + 7 + 9; -e syntax OK V:\>perl -MO=Deparse -e "use constant FOO => 8; $x = FOO + 7 + 9" use constant ('FOO', 8); $x = 24; -e syntax OK
or
V:\>perl -MO=Deparse -e "sub foo {}; sub bar {};$x = bar foo 7, 9" sub foo { } sub bar { } $x = bar(foo(7, 9)); -e syntax OK V:\>perl -MO=Deparse -e "sub foo ($) {}; sub bar {};$x = bar foo 7, 9" sub foo ($) { } sub bar { } $x = bar(foo(7), 9); -e syntax OK

And some modules need to check the availability of some other modules or libraries (DLLs or whatever) and will decide based on that info what other module to load or which version of the code to actually compile.

So it's not just "OK, at this point everything is compiled and we can save the current state to disk and next time (on a different compute) just load it and run".