Support unbounded variadic functions on map parameter keys

[rhdunn]

Where a parameter is defined as a map, then named/keyword arguments bind to keys in that map if the named/keyword argument does not match a parameter name in that function. For example, fn:serialize($data, method: "json").

Motivation

There are several functions that take an option map in XQFO. It can be clunky to construct the map options when calling these functions.

The option map is a common pattern in other implementations. Specifically, MarkLogic makes use of that pattern.

Note

If the argument name is an NCName, the xs:NCName value should be cast to the map's key type using the XQFO type/value casting rules.

The argument name should support string literals, as map keys can contain spaces. In this case, the xs:string type is cast to the map's key type using the XQFO type/value casting rules.

The #159 proposal allows QNames for the argument names in order to support parameters that are QNames. When binding to a map key an error (static or dynamic) should be raised.

[dnovatchev]

I like this proposal.

It can be carried one step further: If the function has two or more parameters whose type is a map, then providing the value for a specific map option can still be done by prefixing it with the name of the map parameter, like:

funWith2MapParams($data, MapParam1?method := "json", MapParam2?method := "SomethingElse", )

[johnlumley]

What happens if an (optional) argument of type map has a keyword that is the same as that of a key of the defined map type? E.g.
foo($a, $bar as map(*))
and we call
foo(123, bar:=map{'a':1})
Is the value of the second argument in the function body now
a map{'a':1} or a map{'bar':map{'a':1}} ?

[michaelhkay]

I like the way this is going, but there are some difficulties: not least, the fact that we need to count the number of arguments in the function call before we know which function we are actually calling. To achieve this, I think we need a syntactic distinction between arguments used to set options, and those that bind to regular named parameters.

I propose the following.

No changes to the syntax of function declarations.

In a static function call, we allow a KeywordArgument to take the alternative form:

KeywordArgument ::= OptionArgument | ...
OptionArgument ::= '?' (NCName | string-literal) ':=' ExprSingle

To compute the effective arity of a static function call, we take the number of arguments that are not OptionArguments, and add one if there are one or more OptionArguments. This enables us to identify the function being called. If there are one or more OptionArguments, they are assembled into a map, and this map is supplied as the value of the last parameter in the function definition. For example given the function call

fn:serialize($input, ?method:='json', ?indent:=true())

we identify this as a call on fn:serialize#2, and convert the function call into the equivalent

fn:serialize($input, options := map{'method':'json', 'indent':true()})

Note: we could add the possibility of writing options?indent := true() as suggested, but I'm not convinced that this is really useful. It makes the rules for deciding which function is being called, based on the number of arguments in the call, quite a bit more complicated.

[michaelhkay]

I propose the following.

(a) function declarations/definitions do not change.

(b) a function call may take the form `fn:serialize($input; method:='json', indent:=true())

Everything after the semicolon counts as one argument, and this argument is bound to the last parameter in the function definition. The value of the argument is a map formed from the supplied keyword/value pairs. The keywords must be in the form of NCNames.

Possible variations:

• Allow string literals as the keywords (feels unnecessary to me, all our current options are NCNames)
• Use a different delimiter ('=' or ':')
• Bind the argument to the parameter named "options" rather than to the last parameter (one benefit would be parser convenience, it means that a function call using ";" can be converted to a conventional static function call without knowing any details of the function definition. Another benefit would be extensibility of function definitions; it becomes possible to add another parameter after the options parameter should this be necessary. However, making "options" a magic name seems ugly.)

[michaelhkay]

In PR #1071, we are proposing that it should become possible to write

fn:serialize($input, {'method':'json', 'indent':true()})

which seems about as good as:

fn:serialize($input; method:='json', indent:=true())

So I propose that we should treat acceptance of PR #1071 as meaning we can close this issue with no further action.

[ndw]

The CG agreed to close this issue without further action at meeting 077.