Re: Proposal for variadic functions

On Tue, 8 Dec 2020 at 13:13, Michael Kay <mike@saxonica.com> wrote:

>
>
> For compatibility, format-date#2 and format-date#5 remain available as
>> references to virtual fixed-arity functions that map directly to the
>> variadic function.
>>
>
> -1
>
> My concern here is introducing functionality that is not defined as part
> of the language in mapping the function references with the special casing
> logic to create virtual-arity functions,
>
>
> I wasn't intending to special-case this. As explained in my reply to Norm,
> the idea is that in all cases where F(a,b,c,d) is a valid function call
> with four positional arguments, then F#4 returns a "virtual" non-variadic
> function with arity 4 that has the same effect as this function call, even
> though F itself is variadic. I think that ties in with your thinking
> explained below.
>

+1

Thanks for the clarification. That ties in with my thinking also.

Kind regards,
Reece

>
> Michael Kay
> Saxonica
>
>
>
> so we end up in the same situation as the current variadic arguments for
> concat, and for context-sensitive functions. It makes it difficult for tool
> vendors to support (especially if the functions the special casing applies
> to varies between vendors), and has the logic of only applying to the
> standard library and not other functions. For example, MarkLogic has a lot
> of functions that have default arguments, so it would be helpful if they
> could support this without having to special case those functions as well.
>
> The way I've approached this for array-variadic functions is to have the
> function arity be a (min bound, max bound) range where a function reference
> or call matches if the argument arity (a scalar value) is within the
> function parameter arity. For a non-variadic function the min and max
> bounds are the same. I could easily see using that same mechanism to
> support bounded-variadic functions. It also means that there is no special
> case logic to define fixed-arity virtual functions, and would allow
> vendor-specific and user-defined functions to be rewritten to make use of
> default arguments while retaining compatibility with any references bound
> to them.
>
>
>> C. Array-variadic functions.
>>
>> In an array-variadic function, the last parameter has an array type. If
>> the last parameter is at position N, then the supplied arguments at
>> position N, N+1. N+2, etc, are combined into an array, and the array is
>> passed as the value of the last parameter. The caller also has the option
>> of passing an actual array as the value of the argument; this is done by
>> using a keyword argument. The array has an implicit default of [].
>>
>> The number of supplied arguments must be >= the number of required
>> parameters (where the array argument is not counted as a required
>> parameter: it effectively defaults to an empty array). There is no upper
>> bound on the number of arguments.
>>
>> Typical example: concat(). All existing calls of concat remain valid, as
>> do function references such as concat#17. But it now becomes possible to
>> supply a single argument as an array, by keyword.
>>
>
> +1 with my caveat around not having function references be special cased
> for variadic functions.
>
>
>> D. Map-variadic functions.
>>
>> In a map-variadic function, the last parameter has a map type. All
>> keyword arguments in the function call are combined into a map, which is
>> supplied as the value of this last parameter. Values for parameters other
>> than the last can only be supplied positionally. It is also possible for
>> the function call to supply the map as a single argument, in which case it
>> must be supplied as a positional argument. The map has an implicit default
>> of map{}.
>>
>> The number of supplied arguments must be >= the number of required
>> parameters (where the map argument is not counted as a required parameter:
>> it effectively defaults to an empty map). There is no upper bound on the
>> number of arguments.
>>
>> Typical example: serialize(). You can supply any keywords you like; the
>> function will ignore any that it doesn't recognise.
>>
>
> +1
>
> This should be supported for record types as well, in which case the
> number of arguments would be bounded and you would be able to have
> validation on the additional arguments. It will also allow tool vendors to
> support better type checking and auto-complete support for those functions.
> If you want it to be open-ended, you could use an open-ended/extensible
> record type.
>
> Kind regards,
> Reece
>
>
>> Michael Kay
>> Saxonica
>>
>
>