Yeah, but that's just a trick identical to using Acme::Bleach. It doesn't really mean perl knows anything about bytecode. In fact, bytecode is foreign to perl. We just don't have any. Not normally.

Foreign? What do you call the units from which the Perl parse tree is made? That's to what I was refereing when I said bytecode. If anything, Perl code is more foreign than this code because perl can't execute Perl code without transforming it into this code first.

The stuff perl is compiled into is called an optree. This is a graph of C structs generally pointing down but with some "up" pointers added for efficiency. I suppose you could serialize the memory to disk but you couldn't just reconstitute it by copying it back into memory. You could invent an abstract serialization for this data like YAML, XML, Lisp, something text based, or something binary. B::Bytecode is one choice that just invented its own format. It's a binary thing and it isn't really related to the in-memory stuff that perl executes. You could dump a program with B::Debug and reconstitute it from that. I don't think anyone wrote a perl->YAML conversion. There's at least two perl->XML conversions, one by TimToady and another by chromatic. I wrote a perl->Lisp in B::Lisp but removed it from CPAN when I decided to abandon it. In all cases the bytecode, YAML, XML, text and Lisp formats are all equally close to perl's own representation which is to say, very far from it.

Systems that actually use bytecode don't treat their program at all like perl. There's a real stream of binary instructions perhaps just like might be used by your computer's CPU. A bytecode "add" instruction might be the byte 0x31. Perl's add instruction is a pointer to the C function pp_add. This doesn't mean a thing as far as performance, AFAIK, but I think it means that bytecode systems get a cheap serialization - just dump the bytecode while optree systems don't.

⠤⠤ ⠙⠊⠕⠞⠁⠇⠑⠧⠊