After a long thunk, I think I thunked of a solution to the 'problem', though I realise that its only a problem if you see any merit in the idea of keeping the bytecode with the source:)
Basically, if the functionality of Inline::Files gets cleaned up--I've had some problems with it, but that probably me trying to use it in ways it shouldn't be used--and rolled into the Perl 6 base, all we would need is another predefined section eg. __BYTECODE__, and it could be done. Of course, as John points out above the fact that the ^Z trick wouldn't work on most platforms means that we would need to used a checksum of the source embedded in the bytecode section. It might also be unfreindly to have binary data stuffed on the end of the source code, some editors would freek. That could be addressed by encoding it with some simple, fast transformation like Byte 64 or similar.
The Parrot engine would simply look for a __BYTECODE__ section and if it found it decode the Byte64; crc or md5 the file (excluding that section), and if it matched the same embedded in the bytecode section, just load and run it.
I guess what I see as the benefit is avoiding the need for make like tools for ensuring that compiled units match their source code. Seperate files are ok but then you get into the whole game of tracking the seperate elements.
Okay you lot, get your wings on the left, halos on the right. It's one size fits all, and "No!", you can't have a different color.
Pick up your cloud down the end and "Yes" if you get allocated a grey one they are a bit damp under foot, but someone has to get them.
Get used to the wings fast cos its an 8 hour day...unless the Govenor calls for a cyclone or hurricane, in which case 16 hour shifts are mandatory.
Just be grateful that you arrived just as the tornado season finished. Them buggers are real work.
| [reply]
[d/l] |