Re: fn:slice()

I haven't been proposing a change to the data model for functions; the definition of the arity of a function doesn't need to change, and I haven't been proposing that the parameters of a function become optional. In fact I haven't been proposing any change to the way functions or their parameters are declared. 

Instead I've been proposing a change to the syntax of a function call, so that arguments can be supplied with keywords, and arguments that are supplied in that way contribute map entries to a map which is supplied as the value for the final parameter in the function's declaration. 

We introduced map-valued option parameters as a design convention for a number of new functions in 3.0/3.1, and it has proved a useful mechanism that's worth exploiting more widely, but the syntax for supplying values for these parameters is certainly capable of improvement. To take an example, a call on fn:transform currently looks like this (XSLT 3.0 test case transform-006):

<xsl:copy-of select="transform( map { 'package-name': 'http://transform-006a/', 
                                                             'package-version' : '1.*',
                                                             'initial-template' : QName('', 'main'), 
                                                             'delivery-format' : 'raw'})?output"/>

and it would now be possible to call it like this:

<xsl:copy-of select="transform( package-name: 'http://transform-006a/', 
                                                  package-version : '1.*',
                                                  initial-template: QName('', 'main'), 
                                                  delivery-format : 'raw')?output"/>

There's no change to the fn:transform function itself, it still has the same declaration, the same signature, the same arity; all that we're doing is providing a nicer syntax for calling it.

Many other modern programming languages provide a similar capability; in Python, it's pretty-well identical to this.

Michael Kay
Saxonica


> On 4 Dec 2020, at 20:17, Dimitre Novatchev <dnovatchev@gmail.com> wrote:
> 
> Also, the definition of "arity" needs to be changed in all places where it is presented, for example in XDM:
> https://www.w3.org/TR/xpath-datamodel-31/#dt-signature <https://www.w3.org/TR/xpath-datamodel-31/#dt-signature>
> from:
> 
> " [Definition <>: A function's arity is the number of its parameters. ] The number of names in a function's parameter names, and the number of parameter types in its signature, must equal the function's arity."
> 
> to:
> 
> [Definition <>: A function's arity is the number of its non-optional parameters. ] The number of names in a function's required-parameter names, and the number of parameter types in its signature, must equal the function's arity.  
> 
> Of course, function subtyping for functions that have optional parameter becomes a mess (Hope not to have such nightmares :)  )
> 
> Thanks,
> Dimitre
> 
> On Fri, Dec 4, 2020 at 12:01 PM Liam R. E. Quin <liam@fromoldbooks.org <mailto:liam@fromoldbooks.org>> wrote:
> On Fri, 2020-12-04 at 18:14 +0000, Michael Kay wrote:
> > I think the bar for new syntax should be much higher than the bar for
> > new functions. Although there might be concerns about "using up" the
> > available space of function names, the space available for functions
> > is vastly greater than the space available for new operators, and we
> > shouldn't use it where a (higher order) function can do the job.
> 
> Overall i agree, and especially about discoverability. But you are in
> effect proposing new syntax with named arguments.
> 
> -- 
> Liam Quin, https://www.delightfulcomputing.com/ <https://www.delightfulcomputing.com/>
> Available for XML/Document/Information Architecture/XSLT/
> XSL/XQuery/Web/Text Processing/A11Y training, work & consulting.
> Barefoot Web-slave, antique illustrations:  http://www.fromoldbooks.org <http://www.fromoldbooks.org/>
> 
> 
>