Re: Variadiic functions

On Tue, Sep 27, 2022 at 2:04 AM 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.
>
>
There is a way to have all these ($options,  $query and $forest-ids) to be
with multiple plurality, without specifying any of their values by keyword.
This can be done if all multiple-pluralities argument values are provided
as the contents of just one array:

    [ [(:  Values of $options :)] , [ (:  Values of $query :) ] , [ (:
Values of $ forest-ids   :) ]]

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

This will not be able to represent any value, which is the empty sequence.
Packing the multiple values as an array solves this problem. I already
raised this problem in the past:  https://github.com/qt4cg/qtspecs/issues/25

Thanks,
Dimitre




> >
> > 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.
>
> Michael Kay
>