Re: fn:slice()

On Fri, Dec 4, 2020 at 2:32 PM Michael Kay <mike@saxonica.com> wrote:

> 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.*',
>                                                   i*nitial-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.
>

This is the most confusing explanation so far. In the call above  there are
4 parameters, but none of them counts as a parameter, and they are not
provided in the function definition signature...

If  package-name,  package-version, initial-template and  delivery-format are
not part of the definition/signature, but the function can be called as
above, then this "definition" is rather lacking... And (what should be) the
important definitions are provided in the specification just as free text
("blah blah blah ...") *. *We don't have a way to specify the type of a map
that should have at least a given subset of key-names, whose values must be
of specific given types. Instead, let us tell the reader a story from One
Thousand and One Nights.

So, one will call the function with any map as parameter and this would be
statically OK?

Is it just me finding this to be a huge disappointment and a huge step
backwards.

Thanks,
Dimitre




>
> 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
> 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>
> 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/
>> 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
>>
>>
>>
>
>