RE: [xsl] XSLT vs Perl

["Michael Kay" <mhk@xxxxxxxxx>]

> 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