True, I didn't mention eval. At least in the case of the "optimized C" back end, I should have. Programs that use eval and want to use this back end would still need to link to perl.dll or perl.so to run. Also, there may be other features of Perl impractical to translate without relying on perl.dll/perl.so

As for Perl bytecode requiring a run time interpreter to execute the bytecode, so does Java bytecode.

As for "run time side effects", I mean does a BEGIN block perform an action that only makes sense at run time.

For example, suppose there's a Expect::Quick module and you use it like:

use Expect::Quick Prompt => [ -re => '^\$\s+' ], REMOTE => 'user@examp
+le.com';

send 'command param1 param2';
my $resp = before;
...;
[download]

The implicit BEGIN block:

BEGIN {
    require Expect::Quick Prompt;
    import Prompt => [ -re => '^\$\s+' ], REMOTE => 'user@example.com'
+;
}
[download]

will create Expect obj, open a connection to example.com and login as "user".

If you saved the bytecode then load and run it later, the connection to example.com will not be done.

On the other hand:

use Expect::Quick;

connect Prompt => [ -re => '^\$\s+' ], REMOTE => 'user@example.com';

send 'command param1 param2';
my $resp = before;
...;
[download]

could be compiled and the bytecode saved. Then later, when loaded and run, it would work correctly.

The dynamic features of Perl would still be available to use.

Of course, it is possible for the actual connect and login to be deferred until the first time send is called. My point is that import would have to be written to do that. And any other BEGIN blocks, implicit or not, could not perform actions that need to be performed at run time. But any and all of Perl's compile time magic is still "in play".