Subject: RE: [xsl] XSLT vs Perl From: "Michael Kay" <mhk@xxxxxxxxx> Date: Thu, 5 Feb 2004 10:01:46 -0000 |
> Writing 'analyse-string' for a thing as simple as addr-spec > RFC2822 (160 ascii characters in length for the regular > expression) is a task for a good regexp hacker. In Perl, C, > Java, one can compose a regexp from parts, store them in a > data structure accessible by keys, provide as many > abstraction layers above parsing as required. You don't seem to have read the XSLT/XPath specs carefully enough. They do allow you to manipulate regular expressions dynamically as strings. You can do all the things you mention. > > A powerful language for string analysis is available for > almost 30 years and called 'lex' (lex(1)). > > > Can you expand on the kinds of grouping problems that you have that > > <xsl:for-each-group> can't handle? I'm not particularly > enamoured with > > <xsl:for-each-group> myself, and it sounds as if you have another > > design in mind; what is it? > > WHy grouping is easy in Lisp, Java, C, and Ruby? Do those > other languages have grouping constructs? Why grouping at all > is a specific family of algorithms? In fact, it is not. It's true that grouping could have been tackled in a different way: rather than creating grouping primitives in the language, it could have been done by providing higher-order functions and a richer data model. I don't think that the result would be better for the target user of the language. This is a question of design philosophy: XSLT has always been seen as a task-oriented language, and the tradition in task-oriented languages is to provide high level constructs that directly address common programming tasks, rather than to provide the general-purpose primitives from which the user can construct their own solution. That's why it has always had high-level constructs to do things like sorting and numbering. If we had taken the second route then you could indeed argue that XSLT had (literally) lost its sense of purpose. You haven't answered the question quoted above: can you identify any realistic grouping problems that can't be tackled using the high-level constructs provided? We did a fair bit of work to collect use cases, and we think the coverage is pretty good, but if there are other cases we haven't considered, we'd like to know about them. Frankly, I find it hard to understand what you're trying to achieve. You don't have to use XSLT; if you want to program everything in Lisp or Ruby, you are welcome to do so. Those languages have their own fan clubs, and I'm not going to make a fool of myself by going onto their forums and telling their users (and designers) that they've got it all wrong. Different languages are optimized for different tasks, different user communities, and different prejudices. If you feel passionately that you can design a language that is better than the one W3C has designed, then go away and design it, and we'll tell you what we think of it when you've finished. Michael Kay XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT vs Perl, David Tolpin | Thread | RE: [xsl] XSLT vs Perl, David Tolpin |
RE: [xsl] Debugging XSLT, David . Pawson | Date | RE: [xsl] Charsets in Saxon, Michael Kay |
Month |