The case for native higher-order functions in XQuery

The XQuery Working Group is debating the need for higher-order functions in the language. I’m working on honing my description of why this is an important feature. Does this work? What would work better?

Imagine you are writing a smallish widget app, in an environment without a standard library. When you need to sort your widgets, you’d write a simple function with a signature like sort(sequence-of-widgets). That’s great.

Now imagine you find your app to be steadily growing. An accumulation of smaller one-off solutions won’t work anymore, you need a general solution. What you’ll end up with is something like qsort in C, which takes a pointer to a comparator function. By providing different comparators, you can sort anything any way you like, all through only a single sort function. C and C++ have something like this, as do PHP, Python, Java, JavaScript, and even assembly language. XSLT has it, as proven by Dimitre.

XQuery doesn’t. It should, because people are now using it for more than short queries. People are writing programs in it. -m

P. S. Comment please.

5 Responses to “The case for native higher-order functions in XQuery”

  1. Rob Koberg

    “What would work better?”

    Uff… use XQuery when XQuery works best. Use XSL when it works best. They both use XPath. This almost a no-brainer from a user point of view. I do understand that XQuery is more ‘optimizable,’ but at what cost? I really think the XMLDB folk hurt themselves when they ignore the strengths XSL brings to the game.

    You are ignoring (dancing around the issue of) the clear advantage of the xsl:apply-templates v. typeswitch. But this would be a non-issue if the XMLDB supported its red-headed stepchild.

  2. Gary VIdal

    Hey Micah,

    Funny you have blogged about high order functions as I have been compiling some specifications myself about Marklogic XQuery extensions that could also make high order functions very useful. One use case that I often find for “functions as first class” would be passing functions to main modules for different strategies for rendering. I was speaking to a few folks from Marklogic last night at the “Customer Appreciation Dinner” and your name seemed to come up as the person to talk to. We should speak more about this topic, as I may contribute a few use cases.


  3. Martin


    I also though about that a bit, see here:

    Rob: I think most XML DB vendors grok that you don’t want to create styles with XQuery. XSLT is great, in particular because of apply-templates. They simply have a different area of application, but I think in most contexts you can very easily integrate XSLT with XQuery, i.e., by post-processing the XQuery result.

  4. Gary Vidal


    Just to share some of my thoughts on Xquery you can see some of my thoughts on

  5. Jim Fuller