Re: Proposal for variadic functions

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
>>
>>
>
> --
> Cheers,
> Dimitre Novatchev
> ---------------------------------------
> Truly great madness cannot be achieved without significant intelligence.
> ---------------------------------------
> To invent, you need a good imagination and a pile of junk
> -------------------------------------
> Never fight an inanimate object
> -------------------------------------
> To avoid situations in which you might make mistakes may be the
> biggest mistake of all
> ------------------------------------
> Quality means doing it right when no one is looking.
> -------------------------------------
> You've achieved success in your field when you don't know whether what
> you're doing is work or play
> -------------------------------------
> To achieve the impossible dream, try going to sleep.
> -------------------------------------
> Facts do not cease to exist because they are ignored.
> -------------------------------------
> Typing monkeys will write all Shakespeare's works in 200yrs.Will they
> write all patents, too? :)
> -------------------------------------
> Sanity is madness put to good use.
> -------------------------------------
> I finally figured out the only reason to be alive is to enjoy it.
>
>