Re: Proposal for variadic functions

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

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