Perl source code is compiled into things called optrees. This is a linked list of things to execute and you can see some parts of this if you use the B::Concise module. Here's an example:

C:\Documents and Settings\Josh>perl -MO=Concise -e "print @ARGV"
7  <@> leave[1 ref] vKP/REFC ->(end)
1     <0> enter ->2
2     <;> nextstate(main 1 -e:1) v ->3
6     <@> print vK ->7
3        <0> pushmark s ->4
5        <1> rv2av[t2] lK/1 ->6
4           <#> gv[*ARGV] s ->5
-e syntax OK
[download]

This is actually just a bunch of C structs and perl is just walking them in order using this ultra simple runloop:

int
Perl_runops_standard(pTHX)
{
    dVAR;
    while ((PL_op = CALL_FPTR(PL_op->op_ppaddr)(aTHX))) {
        PERL_ASYNC_CHECK();
    }

    TAINT_NOT;
    return 0;
}
[download]

Since perl code is compiled into a kind of data, it's actually pretty lispy by this point. You can inspect and modify this data directly.

I'd always thought it was compiled into a bytecode state, similar to java. Was I off in this?

One thing I've never understood is exactly why spitting out something in that intermediate step is apparently such a nuisance. If perl could plunk out the intermediate "compiled" bytecode (or optree or whatever it is), and then pick that up later, I think it'd be keen.

First off, it would skip re-building the blasted tree every time. Yes, yes, I know that it's fast, but if we don't need to do it, we should skip it. But mainly, it'd clarify that yes, perl does compile, and stop the people that claim it's just glorified shell scripting. I'd say perl is as much a compiled language as java is.

But, apparently, that's rather difficult to do, I guess. Can anybody explain why?

As I said above, the compiled form is a bunch of C structs in memory with pointers to each other. You could just dump this directly to disk but then it'd only be meaningful on a perl compiled exactly the same way. To get something you could run on someone else's perl you'd need to normalize it too. People tried doing that with the B::Bytecode module but it turned out that it was faster to go from source to optrees than "bytecode" to optrees.

So it's true that we could substitute parsing source for reconstituting optrees but parsing source is already so fast that there it isn't a win to "skip" it. If you want to try this out on your perl, write the results of perl -MO=Bytecode your-file.pl to disk and then check out the byteloader program. This has been removed in the latest dev versions of perl mostly because in addition to never actually being faster, it also never really worked.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊

First off, it would skip re-building the blasted tree every time.

There's still the deserialization overhead, which is not cheap.

Moving away from a tree representation to formal bytecode would help with that, but it would require such a change to the Perl 5 core that no one who knows how is likely to do it ever.

A compiler runs over source code and generates output code without executing the output code. Generally the output winds up as native machine code that is subsequently executed in a different context.

An interpreter runs over source code and executes it as it goes (possibly compiling fragments into an intermediate representation).

Perl does both. It runs over the source code and compiles it into an intermediate form. It then "interprets" the intermediate form. Note that this gets somewhat more interesting when eval is involved because the code fragment passed into eval needs to be compiled and interpreted in its turn.

Update fix stupidty and add documentation links for eval

Perl does both. It runs over the source code and compiles it into an intermediate form. It then "interprets" the intermediate form. Note that this gets somewhat more interesting when eval is involved because the code fragment passed into eval needs to be compiled and interpreted in its turn.

From perldoc -f eval

In the second form, the code within the BLOCK is parsed only once--at 
+the
same time the code surrounding the "eval" itself was parsed--and execu
+ted
within the context of the current Perl program.  This form is typicall
+y
used to trap exceptions more efficiently than the first (see below),
while also providing the benefit of checking the code within BLOCK at
compile time.
[download]

P.S.: I'm posting this for those like I had somekind of doubt if eval BLOCK interprets and compiles the code inside BLOCK. The answer is no.

Igor 'izut' Sutton
your code, your rules.

However New Shimmer is both a floor wax and a dessert topping.

/J