John Siracusa wrote: > Anyway, what it'll give me is "official" support for this type of thing. In > particular, the Perl 6 executable itself should know what to make of such a > specially formed dir tree" how to adjust @INC automatically for me, what to > run, etc.--in the same way that Perl 5 knows to look for Foo/Bar.pm in @INC > when I use Foo::Bar. It's just nice to have some things built-in to avoid > too much tedious bootstrapping.
Basically what you're saying is that "official" support for this will be better than PAR in some way, since it's official. I'm hearing a lot of this "offical" and "core" tossed around, so I thought I'd just remind everyone of something: Perl 6 is a community project. If you yell out "I want feature X", you have to expect someone in our community to implement it. In the case of PAR, someone in our community did implement it (quite well might I add). Making it "core" just takes the power out of Autrijus's hands and puts it in the core designers' and implementors' hands, which may not be where it ought to be. In this case, I don't see any reason for this to be "core". It has no effect on the way the rest of the language will go, it introduces no idioms, it has nothing to do with the language at all. If you can adjust @INC like you can in Perl 5, you can do everything you need to do to support this in a module. And it's best that we let the community write that module, because the more extraneous features that we put on the 6.0.0 design list, the longer it will take for 6.0.0 to finish, and the longer it will be before people feel like they can seriously write modules for it. Basically, if we put something on the 6.0.0 design list that doesn't need to be there, it will take longer for that thing to arrive. Luke
