This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Request to add a rest parameter to XQuery, in the style of javascript or python. In javascript an ellipsis is used to indicate the parameter should take the remaining parameters as a list and bind them to the prefixed one. Another option would be to suffix the parameter name with an ellipsis (or other). E.g. function($args ... as array(item()?)
Changing this to an XQuery 3.2 requirement, since we're long past accepting new requirements for XQ 3.1, especially anything as fundamental as this. It's something that would be very nice to have (along with optional/defaultable) parameters), but it's not at all easy to achieve, given that currently it's the combination of name+arity that uniquely identifies a function, rather than the name alone. The availability of maps and arrays in XQ 3.1 provides a workaround in terms of allowing more flexible function interfaces; for example see the fn:transform method in which all arguments are supplied as entries in a map.
A function would be identified as a unary one for a single rest parameter. It means there can't be another unary function of the same name. Or am I missing something?
(In reply to WS Hager from comment #2) > A function would be identified as a unary one for a single rest parameter. > It means there can't be another unary function of the same name. But say there's a binary function of the same name. If you write a function call with that name and two arguments, which of the functions are you invoking?
I believe XQuery implementations should override functions in order of appearence, right?
> A function would be identified as a unary one for a single rest parameter. How would you then differentiate unambiguously between different possible signatures? With this rule in mind, suppose you have two named functions declared, same name, like this, but different arities (according to your rules): f:test := function($args ... as array(item()?) { return $args[?1] } f:test := function($x as xs:int, $y as xs:int) {return 1 } What will f:test(42, 42) return? 42, or 1? And what should f:test#1 return (function that takes array or function that takes item()?)? And what f:test#2? Or f:test#99 (i.e., a reference to a function with 99 args, or one with 1 arg that takes an array, or one with 100 args, with the last one taking an array)? I'm not saying it is impossible to device the syntax, but there are likely a lot of cases to consider.
The goal of the syntax is to enable the creation of n-ary functions in xquery, which I sorely miss. I don't think it these cases matter more that that, so IMO anything else should be an override.
(In reply to WS Hager from comment #4) > I believe XQuery implementations should override functions in order of > appearence, right? No, an XQuery implementation must raise static error XQST0034 if it encounters multiple functions with the same name and number of arguments.
(In reply to Michael Dyck from comment #7) > No, an XQuery implementation must raise static error XQST0034 if it > encounters multiple functions with the same name and number of arguments. In that case eXist-db is wrong... An error is even more clear: either multiple fixed-arity functions or a single wildcard.
We might be able to make it work in the current model by saying that declaring a function with a rest parameter adds an infinite set of entries to the statically known function signatures and the named functions. So Abel's example in comment 5 would be a static error, but if we ignore the fixed-arity declaration (and also the odd syntax for function decls), then the questions about named function references remain. My inclination would be that they all return the same function value. That'd be simpler than fabricating an infinite set of different function values, one for each different arity.
(In reply to Michael Dyck from comment #9) > (and also the odd syntax for function decls) Yes, I should have mentioned it was not meant as real code, more-a-less pseudo-code, sorry for the confusion (as in XPath you cannot declare named functions, and this should be a feature of XPath, not XQuery, and be allowed irrespective of whether the function is named or not). > My inclination would be that they all return the same function value. You mean, for instance, that f:test#3 would return an infinite-arity function, or that we forbid f:test#3 (and the overloads) if an infinite-arity function exists? I think, for orthogonality, it should work the same as fn:concat. Which means, there's a single signature with infinite arity (no fixed arity overloads are allowed), where, for instance, fn:concat#8 returns an eight-arity function reference. And fn:concat("foo", ?, ?, ?) returns a three-arity function reference with a single fixed parameter.