On 9/4/04 11:42 PM, chromatic wrote: > On Sat, 2004-09-04 at 18:44, John Siracusa wrote: >> To bring it home, I think packaging and distribution is important enough to >> warrant a standard, core-supported implementation. > >> I think the "specially structured dir of files" and its single-file packaged >> (and precompiled) variants are important enough to be standardized, or >> "core", or whatever you want to call it. > > ... you can find almost anyone arguing this point for almost any > feature. I'm inclined to distrust it.
Yes, this is a hard aspect to get consensus on, but that doesn't mean it's not important. Totally avoiding this kind of question is not the solution, IMO. That said... >> I just don't see a way to achieve this level of transparency and >> elegance without core support. > > That's a much better gauge for whether a feature should go into the > core. I don't know how this particular case fares with that metric, but > it's one of the right questions to ask. I think the most important question was at the end of my last message: is something even *possible* without core support? Taking a set of scripts and libs and making single-file, compiled (or "precompiled" bytecode or whatever) executable that will run on all platforms that merely have a perl6 executable installed is something that *requires* core support, as far as I can see. On 9/5/04 3:02 AM, Simon Cozens wrote: > [EMAIL PROTECTED] (John Siracusa) writes: >> there's an official way, you'll certainly see less wheel reinvention than in >> Perl 5. This is a good thing. > > That is only true if you accept the fundamentalist principle that one should > never reinvent wheels. If that were true, then we wouldn't be working on Perl > 6. Perl 6 will do many things that Perl 5 can't, so its more aptly described as an upgrade :) >> The standardized "class", "method", "submethod", and so on in Perl 6 will be >> an absolute breath of fresh air. > > Don't worry; people will soon create their own helper modules anyway. There'll > still be More Than One Way To Do It, like it or not. Maybe, but I'll wager there'll be a lot less variety since the standard system is more than capable enough for most purposes. Even if it's tweaked a little, if you know the standard system then you have a huge head start on whatever a particular program is doing. Wholesale reinvention will likely be confined to Damians. >> Furthermore, every "non-core" implementation will necessarily be uglier than >> the built-in system. > > Again, this is dogma. If the core specifies every minute detail of what > you can do with the language, it's going to be far uglier than any module or > implementation you can come up with. It's not specifying what you can do, it's providing one (good) way to do it. This brings up (again) the issue of "core" vs "standard lib" and all that. Some features are naturally library functions, but some things either can't or shouldn't be done without core support. The packaging issue spans the whole range: 1. The special dir of files (SDoF). Ignoring, for now, the argument for a standard way to do this, all the core needs to do to bootstrap an entire ecosystem of app packagers is support some standard starting point. Maybe it's a file names main.pl inside a *.pmx dir, or whatever. But there needs to be something, otherwise every SDoF system will have to bootstrap itself using some executable other than perl (e.g. PAR/parl) I think that's much less elegant. 2. The single-file, packaged version of the SDoF (SDoF Package). Too boostrap this, the core needs to know what to make of such a file. Maybe nothing needs to be done if a #! line and some plain old perl code at the start of the file is sufficient. But something tells me that a bit more is 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. 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.) 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. Regardless of whether it's "core" or "stdlib", I think Java benefited greatly from having the JAR format. Perl 6 should one-up Java here like it does everywhere else :) Based on the little I know of JAR, the three features listed above seem to extend a bit beyond JAR in both directions, and each either require or should have some amount of core support, even if only to bootstrap community implementations. But I think a "blessed" family of packaging systems is a big win for the language overall. Just think about how having a standard like CPAN has helped Perl 5. Would it be better to have 20 different CPAN-like thingies? CPAN is certainly not "core", and it has its flaws, the the benefits of its ubiquity are great. 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. -John
