I see three reasons for wanting the "standalone executable" referred to in this thread.

• Avoiding the need to distribute source code with applications.
• Avoiding the start-up costs associated with re-compiling the source for every run.
• Avoiding need to build and install perl on every machine that is to run that application.

Being able to capture and encapsulate the bytecode along with a binary bytecode interpreter addresses the first two.

Allowing that bytecode to use DynLibs goes a long way to addressing the third part of the equation. Making those Dynlibs available without the need to rebuild them on every machine completes it.

Whilst it would be a huge logistical problem to make all the cpan modules available in binary form for all possible target systems, most organisations have only one or two flavours of workstation or server available. Requiring them to build the DynLibs for their own target systems avoids the storage and licencing issues associated with doing this from a central super-corporate location like cpan. They could then choose to locate copies of these DynLibs either locally or on the network.

I appreciate that they could make the perl interpreter available via nfs or similar, but the need to pull everything across the network, interpret it each time a script is used causes a huge run-time penalty.

Allowing pure perl modules to be used in their bytecode form, would vastly reduce this runtime hit. The only fly in that ointment (that I see) is, as you pointed out, non-Perl extensions. These are the Dynlib parts that would need to be built locally.

Under this scheme Perl would consist of several parts.

Development time source compiler with embedded runtime interpreter. Capable of running an application from source as now, also capable of spitting out a platform-independant bytecode 'image' of the application. This could consist of either just the 'application code' or that application code plus the bytecode for any pure perl module dependancies controlled by a switch. In either form, it would contain the fix-up information required to call binary DynLib dependancies through the platform specific interface module described earlier.

The runtime perl would consist of a platform specific binary bytecode interpreter with the interface module built-in. It would be possible to invoke this and point it at one of the bytecode applications, and it would run much as now.

I would also be possible to 'attach' an applications bytecode to a binary runtime and turn it into a platform specific binary application. This would still invoke the Dynlibs via the interface module, but would ease the packaging and distribution.

In corporate terms, the ability to distribute applications to workstations and servers in bytecode form, whilst not completly preventing localised tinkering, would make it sufficiently hard that it would prevent it from being casually done. This would, in and of itself, be worthwhile.

For the small software developer, it would allow the development of saleable application programs in markets that don't want to concern themselves with compliers and sourcecode management. They might also need to zip the application up with the appropriate platform specific binary libraries, but this is SOP for developers in these markets as exemplified by the VB runtime libraries.

There are undoubtably still holes in my argument, but I don't see any show stoppers other than the resistance of status quo.

I saw your comments elsewhere regarding the quality of the new breed of Perl programmer, and in some ways understand them, but I don't think keeping perl the exclusive domain of ....I'll let you choose your own phrase here... would be to the benefit of Perl in the long run. I could be wrong on that, but LW seems pretty determined to ensure that Perl remains accessible to the newcomer and I have no reason to challenge that.