all makes good sense, to make a poor analogy (and to make my point);
the java build tool, Apache Ant went through the same sort of cycle (at a much smaller scale) whereby initial architecture forced a lot of extraneous functionality into the core .... hard to maintain and limited deployment profile capability was the result. With Ant's latest incarnation, they finally have a good model for extensibility and have been successful at segregating axiomatic functionality to the core and relegating extensions to external libraries. I completely agree that this is also good approach for Perl 6 .... but I would weakly argue that XML ubiquity is fast making it the 'text' format of the day and perl having many text processing facilities built into its core might want to reconsider some basic premises about how it perceives XML. A few things I could imagine; native XML data type (and whatever that means at this late stage) .... xml parser, xpath processor built into Perl6 core making it very quick, since we are late stage I would call this an optimization ;), I can even see in a moment of madness a nod to 'whatever' programming and embed some triple inference processing deep into perl6..... making perl 6 XML-neutral is a mistake. imho. cheers, Jim Fuller On Nov 28, 2007 7:12 PM, Nicholas Clark <[EMAIL PROTECTED]> wrote: > > On Wed, Nov 28, 2007 at 06:06:14PM +0100, James Fuller wrote: > > there seems to be a dearth of xml 'ness' in Perl 6 design ... perhaps > > before Perl 6 is fully its time to review what could live in the > > core versus an external module. > > > > thoughts? > > If I remember the plan correctly, it's roughly that the core consists only of > the mechanisms for getting and installing other extension modules - anything > that doesn't need to be in the core, isn't. > > This slim core intentionally won't be useful for that much, other than the > basis for building larger Perl 6 distributions aimed at broad types of tasks. > The idea being that an ISP would install the "web serving" distribution, > which would be bundled with the sorts of modules appropriate for that task, > but not burned with the sorts of modules useful for bioinformatics. > > The aim is to avoid the problem that Perl 5 finds itself in, where things > once added to the core can never be removed, and 15 years later you find > that there are several generations of "this is current" modules in the > distribution that are a maintenance burden. Usually a burden that falls on > volunteers. > > Nicholas Clark >
