I think you're confusing my portability and scalability issues with others requirements for speed and/or obfuscation. I have stated on PM that 'Perl just gets better and better" and I meant it. I don't have issues with Perl's speed.

Also I do have programs that were compiled in 1990 on pre-released IBM RS/6000 computers running AIX 3.0 beta ( AIX 3.1.5 was the official release in 1991 ) that can run today on 'power 7, p-series computers running AIX 7.1'.
The computers are binary compatible even though the source code doesn't compile. K&R 'C' is considered traditional today, and most 'C' products no longer support traditional code.

IMHO, if you ever have to authorize a '10 man-year' project to manually update source code on 2500+ computers, instead of remotely updated the compiled code over a weekend, then maybe you would see it as a little bigger and different problem.

Python seems (I've never programmed in it) to cache compiled bytecode and keep it next to the original source code everwhere, http://docs.python.org/release/1.5.1p1/tut/node43.html. Maybe a similar concept should be added to Perl. If the version, or CRC or timestamps dont match it is recompiled and saved disk.

That would enhance Perl, but would not solve the lack of 'opcodes integrity' from release to release. Maybe the 'use 5.8.8;' could be enhanced to use/force the bytecode to be the same as used for release 5.8.8.

As a programmer, Perl is a fantastic tool.

From the perspective of upper management that authorized the salary for the programmer, it's a tool that end-users can change. We hear all the time on PM "I can't use CPAN" or "I don't have access to a compiler", or ... And then we get the tech answer of 'You too...' But that's not the answer?

The question is coming from someone who is listening to his/her management, and management wants to control the use of the company's computer resources.

A technical answer is not relevant.

Upper management doesn't care how easy/hard it is for the programmer, they want to know that if the software gets deployed to the organization, then it will work the same everywhere.

Aiui it is, or would be, a monumental (I think that's an understatement) social and technical task to bring bytecode, and bytecode discipline, to the current Perl 5 compiler.

But the story is different for Parrot. And different again for Perl 6. And different again for Perl 5 in the light of Perl 6.

Parrot is a tough call. As others have said, bytecode stability was part of the original plan. It doesn't have that now, but that doesn't mean it couldn't, and won't ever. Otoh, to say they have more pressing concerns, and lack of tuits, is an understatement. Unless you are confident you could live for a few years without oxygen if you had to, I recommend you don't hold your breath waiting.

Perl 6 also has more pressing concerns, and also has less resources than it needs, but it's a much more reasonable proposition regarding generation of bytecode and discipline to keep it forward compatible as they add or change opcodes.

There are several Perl 6 compilers that generate bytecode. In particular, Niecza is pretty advanced and currently generates CLR bytecode and Rakudo is also pretty advanced and currently compiles down to Parrot bytecode. Aiui both these compilers are likely to be portable across different bytecode backends soonish; perhaps one will even manage that this year.

And a few days ago someone spotted Larry Wall working on a Perl 5 parser written in Perl 6, something that's gotta be way easier than working on the current Perl 5 compiler...

Ed,
I'm no expert but I think you may be a bit confused.
Your "Perl 5 Compiler, Again!" thread definitely did NOT prove that the "compiler topic is near impossible to solve". That thread was basically just one tit-for-tat between chromatic and Reini Urban, who are on opposite sides of the fence on this particular issue, and who are apparently also not the best of friends. Nothing solid can be deduced from that thread.

The bytecode issue is only one aspect of the complicated optimizing problem. We may be able to produce a Perl 5 optimizing compiler without use of the Perl bytecode system at all. On the other hand, bytecode may turn out to be a critical component in optimizing, only time will tell.

Perl 6 seems to be a pipe dream. Perl 5 seems to be stabilized and mostly in maintenance mode. I'm not interested in creating Perl 7, since Perl 6 needs to happen first, if ever. I'm interested in compiling & optimizing Perl 5, and this is what I will achieve. :-)

I don't think I'm confused about how to write a compiler, since I was very much involved in that in the past.

What you are minimizing is the '...lack of bytecode integrity' on the impact of developing a compiler for Perl. This is a religious decision and not a technical issue. Your attempts will fail because the Perl developers don't want you to succeed. Each new version of Perl will need a unique compiler. So you come out with your Perl compiler 5.20.0 and the next week Perl 5.22.0 is released, and the Perl developers point out that you compiler 5.20.0 doesn't work with 5.22.0. True, because now you have to use the bytecode structure of 5.22.0 for your 'new/updated' compiler, and your always in catch up mode.

Notice, how many are quick to point out that the early attempts at compilers were always 'out of date'.

I wish you luck, but I was only half joking about Perl7. Perl's strength is The Programming Language, not that it's an interpretative language. Of course you need source code, and to develop the software product you need the power of running in an interpretor, but then you need a compiler to distribute the product. Perl5 has two of the three, and will alway have two of three.

flexvault, my current plan doesn't necessarily involve utilizing the Perl bytecode representation as a significant part of the optimization process. I'm hoping this and utilization of Reini's B system will avoid the "always out of date" issue.