Re: Variadiic functions

On Tue, 27 Sept 2022 at 10:04, Michael Kay <mike@saxonica.com> wrote:

> >
> > The main thing that jumps out at me are how these new rules work when
> there are a mix of parameters. For example, MarkLogic has mixed functions
> that look like:
> >
> > declare function cts:correlation(
> >     $value1 as cts:reference,
> >     $value2 as cts:reference,
> >     $options as xs:string* := (),
> >     $query as cts:query? := (),
> >     $forest-ids as xs:unsignedLong* := ()
> > ) as xs:double? external;
> >
> > IIUC, I don't think this will work with the proposed rules --
> specifically:
> > > * If there is a parameter declaration with plurality=multiple, then
> any remaining positional arguments are aggregated as a sequence and matched
> to that parameter declaration.
> > gives no way of specifying the parameters for $query and $forest-ids in
> the above function example.
>
> If $options, $query, and $forest-ids are all optional, then I don't think
> there's a problem.
>
> If you want to make $forest-ids multiple, then under my rules it needs to
> be declared BEFORE the two optional parameters, and the values of $query
> and $forest-ids can only be supplied by keyword.
>
> If you want to make $options multiple, then you need to supply $query and
> $forest-ids by keyword.
>

I think I understand. I would need to read over and think about this
proposal more carefully, and think about the semantics and how they work in
practice with existing functions. It would help to have a more precise
specification to go over.


> > The rationale for allowing QNames (EQNames in the grammar) is that the
> Param in a function declaration supports QNames, so if when calling a
> function the naming of a parameter is limited to NCNames, then you cannot
> use that with function parameters that are QNames. -- This leads to an
> asymmetry in the behaviour and results in an error that a user would expect
> to work. (Note: In my proposal in issue #54 I've made specifying a QName
> value for a map key an error.)
>
> I think the problem is that the standard options parameters in functions
> like serialize() and map:merge() (anything that uses the option parameter
> conventions) expect strings as the keys, not no-namespace-QNames. So when
> aggregating parameters into a map, unprefixed names have to be treated as
> strings rather than QNames. That's messy, but it's probably doable.
>

It was my intention to support/allow this. I've added a comment to issue
#54 and modified that part to read:

> An NCName uses the local-name as the key in the constructed map cast to
the key type of the map. This follows the XQFO casting rules with the
source type of the local-name being xs:NCName and the target type being the
map's key type.;

As I note in the comment, that should work in the case of serialize(),
map;merge(), etc. as an xs:NCName is a child of xs:string, so will simply
be upcasted to an xs:string.

Kind regards,
Reece