[Bug 29722] [FO31] fn:sort, array:sort

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

--- Comment #9 from Michael Kay <mike@saxonica.com> ---
Let's try to summarize the arguments in favour of different options.

(A) Although it's not absolutely essential, I think we should stick with the
convention that when we have several signatures for a function, the function
with arity N is "compatible" with the function with arity N+1 in that it's
essentially equivalent to calling the arity N+1 function with the last argument
taking a default value.

If we stick with this principle, then 

(i) if we have a function sort(sequence, collation, comparison-function) then
we can also have an arity=2 function sort(sequence, collation) (with
comparison-function defaulting to data#1) 

(ii) if we have a function sort(sequence, comparison-function, collation) then
we can also have an arity=2 function sort(sequence, comparison-function) (with
collation defaulting to the default collation from the static context).

(B) In all existing functions that take a collation, the collation argument
comes last and can be omitted, with a well defined default.

(C) In all existing functions that take a function argument, the function
argument comes last; in some cases it is mandatory and in others it can be
omitted.

The reason we put the function argument last in existing functions was
primarily because of the readability of calls like

fn:filter($x, function ($i) {
  if (x) 
  then typeswitch (x/y)
       case a:
         something
       case b:
         something else
  else zimbo
})

Basically, putting further arguments after the function argument in such cases
is like putting a lengthy parenthetical remark in English text: it requires the
reader to reset a mental stack and remember where they were.

And I think that's the primary argument for doing fn:sort this way.

The counter-argument is probably that the collation is more likely to be
defaulted than the comparison function. While this may be true, I think that
allowing the collation to be supplied as "()" is acceptable.

So I'm inclined to defend the way we currently have it. Certainly, any
arguments for the two approaches are finely balanced and I don't think there's
a convincing case for change.

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

Received on Monday, 12 September 2016 09:11:59 UTC