Re: Keyword arguments and fn:serialize [was fn:slice]

On Sun, Dec 6, 2020 at 10:41 AM Benito van der Zander <benito@benibela.de>
wrote:

> Hi,
>
> this also started as a way to simplify calling the serialize function with
> its parameters.
>
> Do we want a 23-arity serialize function?
>
> fn:serialize($arg as item()*, $allow-duplicate-names as ...,
> $byte-order-mark as ..., $cdata-section-elements as ..., $doctype-public as
> ..., $doctype-system as ..., $encoding as ..., $escape-uri-attributes as
> ..., $html-version as ..., $include-content-type as ..., $indent as ...,
> $item-separator as ..., $json-node-output-method as ..., $media-type as
> ..., $method as ..., $normalization-form as ..., $omit-xml-declaration as
> ..., $standalone as ..., $suppress-indentation as ..., $undeclare-prefixes
> as ..., $use-character-maps as ..., $version as ...)
>
>
Hi Benito,

In the proposed way to define and use keyword parameters/arguments there is
nothing that prohibits the use of a map-typed argument.

In a past thread I even proposed providing the whole hierarchy of standard
functions as one, well-structured and semantically-organized map, which can
help learning / memorizing / grouping / using the standard functions, can
almost eliminate the possibility for naming conflicts and help the
developer and reader of the code at any point to understands precisely
which group of functions are being used.

Thanks,
Dimitre




>
> Although what really matters is the method. Perhaps it could be pulled out
> to create 4 functions:
>
>
> fn:serialize-xml($arg as item()*, $params as item()?) as xs:string
> fn:serialize-html($arg as item()*, $params as item()?) as xs:string
> fn:serialize-xhtml($arg as item()*, $params as item()?) as xs:string
> fn:serialize-json($arg as item()*, $params as item()?) as xs:string
>
>
>
>
> Or perhaps look at the map constructor again.
>
> When you write map { ... something .. } it is like passing the data
> between {} to "map". Map kind of behaves like a function turning the data
> into an actual map.
>
> That could be allowed for all functions. So you could write serialize {
> "method": "xml", ... }
>
> Not sure how that should get its $arg. Perhaps $arg => serialize {
> "method": "xml", ... }
>
> Cheers,
> Benito
> On 05.12.20 22:01, Dimitre Novatchev wrote:
>
> 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.
>
>
>

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