On Sun, Sep 05, 2004 at 10:40:24AM -0400, John Siracusa wrote: > 3. The single-file, platform independent, non-source executable (P6exe). > This is bytecode or some other platform neutral representation of the SDoF. > I just don't see how to do this at all without core support. (Well, I > suppose it could try to #! boostrap as well, but then you'd have to inline a > bytecode interpreter or find some way to feed the bytecode to the right part > of perl 6, which seems like it also leads to some sort of core support.)
There is core support for this in perl5. use ByteLoader puts a source filter module in place that reads the rest of the file in as perl5 bytecode. But as Simon says in another message, this bytecode is bigger and slower to load than perl source. > needed to unzip/untar/whatever the rest of the stuff in the package file > before execution. Trying to inline pure perl unzip/untar at the header of > each SDoF Package file doesn't seem elegant to me, but it could be > technically possible to bootstrap that way using only the perl 6 executable. Or in perl 5. > The B:: family of modules in Perl 5 are fun, but Perl 6 is supposed to do > this better. The perl 6 core needs to be designed with this type of stuff > in mind. Parrot is being designed with this stuff in mind. This is far more a parrot issue. Parrot has directly serialisable bytecode, and can run bytecode from disk. > I think packaging has the same characteristics. But unlike CPAN, packaging > does require some minimum amount of core support to meet what I consider to > be the minimum standard of elegance. I think that this is true. I'm not sure what the minimal list is, and I suspect that really it's more a parrot issue than a perl 6 syntax issue. Nicholas Clark
