As far as I understand, no object output file is created during compilation of perl code and While running the code , each line is interpreted and executed before proceeding to next line.

Perl is neither purely compiled; nor purely interpreted. It is a bit of both and neither.

The perl executive reads the whole program and "compiles" it into an intermediate form, which then gets interpreted. Changing the source of your Perl script from within the program comes too late as your program has already been read in and compiled and it runs now out of its internal represenation which is utterly disconnected from the source text.

Not to mention the notion of "changing the source-code in mid-flight" is incredibly dangerous even if it did work.

...each line is interpreted and executed before proceeding to the next line.

Test your intuition:

while( <DATA> ) {
    chomp;
    if( is_empty($_) ) {
        print "$.: ---\n" if is_empty($_);
    }
    else {
        print "$.: $_\n";
    }
    goto JUMP if $. == 4;
}

sub is_empty {
    return ! length $_[0];
}


BEGIN { print "Beginning execution.\n" }

JUMP: { print "Look, found the JUMP block.\n"; }

__DATA__
First line

Third line
Fourth line
Fifth line
[download]

So... the BEGIN{} block executes before everything else. So Perl must have known about it even though it appears physically lower in the file. The is_empty function is declared and defined after it is called, so Perl must have known about it when it executed the line "if( is_empty(...". And the <DATA> filehandle is being read even though its contents appear at the end of the file. And last but not least, goto found JUMP.

And for what it’s worth, every such language (PHP, Python, Ruby, etc.) does something similar, with variations.   The source-code files are located and, if you will, “semi-compiled” into the data structures that actually drive the execution-engine.   The relationship between the two is very fluid:   you can on-the-fly eval certain text-strings, require certain files, and so on.   But there are still two (or more) distinct stages in the process ... getting from source-code to what is actually executed; and, executing that.

Even a great many “pure compilers” do something very similar, because there is very little pragmatic overhead to this vis-a-vis “straight code,.” and very-appealing space savings.   Even the venerable Apple-][ computer had a “Sweet-16” p-machine as part of its Integer BASIC!

Does this surprise you? What are you trying to do?

Or is there any other way , execution of perl script happens ?

If you want to change your perl script at runtime you have several options including eval, the e modifier on regular expressions and running generated script in a sub-process.

I can't think of any reason to do this other than this demo. What this program does is read itself into a $variable, then it modify that copy of itself, and then it runs that modified code via an eval. The eval causes the modified copy to be compiled and run. So result is 50 on the first run and 15 on the "second" run!

There are FAR better ways of doing this! If you could explain the problem that you are trying to solve, I am sure the Monks can come up with a solution.

#!/usr/bin/perl -w
use strict;
use Data::Dumper;

my $n1=5;    #any numeric value
my $n2=10;   #any numeric value
my $result = $n1 * $n2;
print "$result\n";

#__END__

seek (DATA,0,0);
my $program = do { local $/; <DATA> };
$program =~ tr/*/+/;
$program =~ s/#__/__/;  #prevent infinite loop
eval $program;

__DATA__

=prints
50
15
=cut
[download]