On Wed, 2007-11-28 at 19:59 +0100, James Fuller wrote: > XML Parser is what I am talking about
OK -- do you want an event-based parser? Do you want a DOM parser? Do you want a simplified tree generator parser? Do you care about memory limitations? Run time? Does the parser need to be robust against non-compliant XML documents, or is all the data you will be parsing known to be perfectly conformant with specs? Can you take advantage of the fact that all the XML you need to parse was previously written by your own code in the first place? Conversely, are you willing to *always* pay the performance cost associated with security against complete garbage or carefully crafted evil in the input stream? What about parsers that are optimized for particular schema? (For example, that parse an XML dump of a relational database back into a stream of rows to be pushed efficiently into actual RDBMS tables without having to fit the entire database in memory?) Most importantly -- are you sure that *any* of us can make all those decisions for everyone? Are you sure it's even possible to balance all these requirements? Even if we try to handle the "common" cases, who decides what those are? I guarantee that HugeBank.com and MyFamilyWebsite.net have different views of what the common cases are. > and I would argue that XPATH is > simple and standard enough to be included as well. I have used XPath exactly once, ever, and it wasn't really necessary even then. For some tasks, yes, it's a standard tool. But the world is much, MUCH bigger than that. > putting it more harshly ... I expect my basic programming language to > solve my basic problems without having to resort to some layer of > abstraction in the form of a framework or external module for the > simplest scenarios. This view frustrates me. I want my programming language to provide me expressive power. And I certainly do want modules available should I choose to be Lazy. But I don't expect that someone in a totally different business (or hobby) should want the same modules I do. That's what CPAN6 is for. Or task-related bundles, for that matter. We should not ship CGI *as core*. We should not ship XML tools *as core*. Frankly, I don't think we should ship DBI *as core*, even though I use databases ever day. But these APIs should be available easily. In fact, I expect to be able to intall Bundle::IntarWeb and get them all, plus all sorts of other useful goodies. But what if I am (say) wanting to ship a video game written in Perl. Why should I have to ship all that web-related crap? But I *will* need to ship an OpenGL binding. Which I would guess is totally unimportant to you, while being vitally important, completely basic, and utterly standard (XML is for youngin's, dagnabbit) to me. The Python folks want to ship "batteries included". I want Perl 6 to ship a Mr. Fusion Home Energy Reactor and an easy way to download power adapters. > I have a lot of XML in front of me in all projects that I work on in > every programming context and have had so for the past 3-4 years. I am > a bit biased, but I can only see more XML for all of us. Sure. But the world of XML is not the whole world, just as the world of English is not the whole world -- despite the great difficulty many of us have in recognizing that and writing our software accordingly. > I do not nec. agree with 'a particular grammer is not' part of the > core ... if that grammar is so common to every problem (like regex is) > then why not include it? But that's just it -- it's not common to every problem, only to the problems *YOU* face. I don't by any stretch of the imagination intend this to be a personal attack, by the way. I'm merely saying that numerous people have made similar claims about the feature they need every day being rightfully core. But in nearly every case, that feature was important to *them*, and perhaps even a large class of people, but not to *everyone*. And on occasion, some feature has gotten added to core because it can be used in many different circumstances, or because it's simply not possible to efficiently or easily handle the problem without additions to core. Hence the reason for the amazingly powerful grammars -- you can write parsers in Perl 5 regex (and most of us have), but it's painful, and no amount of tweaking and extending them can make the massive leap in usability and expressive power that Perl 6 grammars bring. With the grammar core in place, XML can be efficiently and easily handled by modules. So it should be. -'f
