Re: Keyword arguments [was fn:slice]

What about something as simple as this:

myFunction($arg1 as item()*, $arg2 as xs:integer default: 15, $arg3 as
xs:string default: "Hi")

This isn't breaking the syntax and semantics of previous versions of XPath.
The arity is 3, not two or one.

It can be called in these ways:

  myFunction(/*/name)  (: will use the defaults for $arg2 and $arg3 :)

  myFunction(/*/name, 12)   (: $arg2 is entered as a positional argument
(which is OK), will use the default for $arg3 :)

  myFunction(/*/name, 12, "Yes")  (: Both $arg2 and $arg3 are entered as
positional arguments, this is OK :)

  myFunction(/*/name, $arg3: "Yes")   (: the default will be used for $arg2
:)

  myFunction(/*/name, $arg2: 12)  (: the default will be used for $arg3 :)

  myFunction(/*/name, $arg3: "Yes", $arg2: 12)  (: when an argument is
provided with name and value, order doesn't matter :)

and even:

 myFunction($arg1: /*/name)  (: we can provide a positional argument using
its parameter name :)

 myFunction($arg3: "Yes", $arg2: 12, $arg1: /*/name)  (: when an argument
is provided with name and value, order doesn't matter, even if this is a
required, positional parameter :)

I think this is more or less the ways for calling a method in C# (
https://docs.microsoft.com/en-us/dotnet/csharp/methods).
To quote the same document (
https://docs.microsoft.com/en-us/dotnet/csharp/methods#method-invocation)

"*You can also use named arguments instead of positional arguments when
invoking a method. When using named arguments, you specify the parameter
name followed by a colon (":") and the argument. Arguments to the method
can appear in any order, as long as all required arguments are present. *"

Thanks,
Dimitre


On Sat, Dec 5, 2020 at 1:16 AM Michael Kay <mike@saxonica.com> wrote:

>
> So Mike's example is exactly what i was suggesting before in this
> regard, except i want the keywords to map to named arguments so there
> can be useful static type checking. We would need to allow optional
> arguments for transform() at least, though, and refer to it e.g. as
> fn:transform#*
>
>
> My only problem with this proposal is whether it can be made
> backwards-compatible. I guess that in a strict sense, if a parameter has to
> be declared optional before it can be used in this way, then existing code
> that doesn't use optional parameters won't be affected. But at a usability
> level, if different functions follow different conventions, then it could
> make life difficult for users.
>
> In the case of system-supplied functions, we've been very careful in the
> design to ensure, for example, that format-date#2 and format-date#5 have
> consistent syntax and semantics, so we could simply make the last three
> parameters optional and turn it into a single function, and a call with any
> number of supplied arguments could bind to format-date#5 without
> difficulty. For compatibility, dynamic references to format-date#2 and
> format-date#5 would still need to work, and for strict compatibility,
> function-arity(format-date#2) would still have to return 2, while
> function-arity(format-date#5) returns 5, so they would still be different
> functions.
>
> For user-written functions, it's possible that users haven't followed the
> same conventions, and my:ftingle#2 might do something completely different
> from my#ftingle#5, so that my:ftingle#2 isn't equivalent to my:ftingle#5
> with optional parameters. This means that calls on user-defined functions
> wouldn't be able to use the new mechanism unless the function definition is
> changed;. Some function libraries such as the EXPath file and binary
> libraries are unlikely to change in a hurry; and until they do, users would
> have to be aware that the new calling mechanism is available for some
> function libraries and not for others.
>
> By contrast, the mechanism I have been proposing of assembling keyword
> arguments into a map requires no change to existing function signatures or
> implementations.
>
> Another difference is that my proposal allows the set of accepted keywords
> to be dynamic and/or extensible. It's possible with a Record type
> definition in the signature to restrict the available keywords, but you
> don't have to. The specification of a function can make it extensible if it
> chooses (so an implementations might accept vendor-defined keywords, as in
> fn:serialize()) and it's also possible to design functions where the set of
> keywords is completely open-ended, for example one could design a function
> where the call
>
> new-element('p') => with-attributes(class: "note", role: "footnote", date:
> current-date())
>
> accepts any set of names for the attributes of a new element.
>
> 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.