29713 2016-06-29 10:59:50 +0000 Feature request: add rest parameter 2016-06-30 09:59:31 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.2 Use Cases and Requirements Working drafts PC Windows NT NEW P2 normal --- 1 wshager jonathan.robie abel.braaksma jmdyck mike public-qt-comments oldest_to_newest 126855 0 wshager 2016-06-29 10:59:50 +0000 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()?) 126856 1 mike 2016-06-29 11:21:32 +0000 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. 126857 2 wshager 2016-06-29 11:36:04 +0000 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? 126858 3 jmdyck 2016-06-29 12:47:56 +0000 (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? 126859 4 wshager 2016-06-29 12:54:16 +0000 I believe XQuery implementations should override functions in order of appearence, right? 126860 5 abel.braaksma 2016-06-29 12:56:08 +0000 > 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. 126861 6 wshager 2016-06-29 12:59:34 +0000 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. 126862 7 jmdyck 2016-06-29 13:05:58 +0000 (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. 126863 8 wshager 2016-06-29 13:09:56 +0000 (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. 126866 9 jmdyck 2016-06-29 15:33:55 +0000 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. 126868 10 abel.braaksma 2016-06-30 09:59:31 +0000 (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.