[Bug 26799] [XP31] operator namespace, for compatibility and for use in higher order functions

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26799

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike@saxonica.com

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
This has been requested and rejected before, though I'm afraid I can't
immediately find the link.

The main objection to doing it, I think, is that the functions were never
designed for this purpose. If you consider using one of the boolean functions
that does comparisons, for example, as an argument to fn:filter(), you quickly
find that you need le, ge, gt, and ne variants of the function as well as
equals() and less-than() variants; and for strings, the compare() function is
useless because it doesn't return a boolean. If you look at the arithmetic
functions, things like op:multiply have a precondition that the two arguments
are the same primitive type, but they define no error condition when they
aren't, because they expect the caller to have taken care of this (by applying
numeric promotion rules to "equalize" the arguments). So the whole library
would need to be re-designed to make it usable.

A second objection is that a large number of tests would need to be written: we
don't have the resources to do this.

I do think it would be nice if there were a more concise way of expressing a
function such as

declare function($x, $y) {$x + $y}

Rather than using a built-in name op:numeric-add#2 for this function, I think a
much more useful enhancement would be to provide a concise syntax for inline
functions, along the lines of Scala and other modern functional programming
languages. For example

λ{$1 + $2}

where the presence of $1 and $2 both declare the argument and indicate how it
will be used. The construct F{$1 + $2} is more concise than op:numeric-add#2,
and it is also far more general. For example consider

sort(//employee, λ{$1!@salary})

I chose λ, of course, so we could have a boke-shed argument about the concrete
syntax. (It's a lambda, by the way, in case Bugzilla ever repeats its old trick
of throwing away non-ascii characters).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 16 September 2014 08:04:27 UTC