Re: Proposal for variadic functions

  Thank you, Reece!

Dimitre

On Tue, Dec 8, 2020 at 9:34 AM Reece Dunn <msclrhd@googlemail.com> wrote:

> On Tue, 8 Dec 2020 at 16:50, Dimitre Novatchev <dnovatchev@gmail.com>
> wrote:
>
>>
>>
>> On Tue, Dec 8, 2020 at 8:36 AM Michael Kay <mike@saxonica.com> wrote:
>>
>>
>>> As other people asked, I don't understand what "virtual fixed-arity"
>>> function means. Please, elaborate and provide an example.
>>>
>>>
>>> I hope my explanations to Norm Tovey-Walsh and Reece Dunn explained the
>>> general idea. Obviously the detailed spec remains to be written.
>>>
>>
>>
>> Nope, maybe I am still not fully awake. The word that halts my thinking
>> process is "virtual". Seems like if we accept arity to have two components
>> this all "virtuality" will be unnecessary? Extra rope to hang themselves?
>> :)
>>
>
> A better description/definition for this may be something like...
>
> A function reference f#n to a bound- or array-variadic function is
> equivalent to creating an inline function expression with arity n that
> calls f with the parameters in order. If the arity of the function
> reference does not fit within the bounds of the variadic function (as
> described by the rules for calling a variadic function), an XPST#### error
> is raised.
>
> > Example:
> > fn:format-date#4 is equivalent to function ($a1, $a2, $a3, $a4) {
> fn:format-date($a1, $a2, $a3, $a4) }.
>
> The resulting function reference is not variadic.
>
> ---
>
> This way, the definition avoids adding new terms that only apply to this
> proposal where other concepts/terms for those exist elsewhere in the
> specification. It also allows an implementation to not create an inline
> function expression if the validation/behaviour is the same -- this is what
> Michael Kay meant by "virtual fixed-arity" (e.g. an implementation could
> reference the variadic function directly but use the arity of the function
> reference for validation, so not create an inline function expression or
> add a new function to the static context).
>
> Kind regards,
> Reece
>
>
>>>
>>>>
>>>> Because in a function call we can reference now any argument by name
>>> (even a positional argument), we must specify a restriction that the (names
>>> of the) keys of the map do not clash with the names of the positional
>>> arguments, or to allow in this case a mechanism for disambiguation,
>>> something like:
>>>
>>> This is why I specified that arguments supplying parameters prior to the
>>> final map parameter cannot use keywords, they must be specified
>>> positionally.
>>>
>>
>> This is completely unnecessary, restricting and damaging the completeness
>> of this unified proposal.
>>
>> -10
>>
>> Thanks,
>> Dimitre
>>
>>
>>>
>>> Michael Kay
>>> Saxonica
>>>
>>>
>>
>>