Re: New XPath draft

On Sun, 13 Dec 2020 at 18:20, Dimitre Novatchev <dnovatchev@gmail.com>
wrote:

> Here are some initial comments and questions:
>
> *Quote*:
>
> "*4.3.5 Static Function Calls*
> The expanded QName
> <https://qt4cg.org/branch/master/xquery-40/xpath-40-diff.html#dt-expanded-qname> and
> number of arguments in the static function call must match the name and
> arity of a function signature
> <https://qt4cg.org/branch/master/xquery-40/xpath-40-diff.html#dt-known-func-signatures> in
> the static context
> <https://qt4cg.org/branch/master/xquery-40/xpath-40-diff.html#dt-static-context>;
> if there is no match, a static error
> <https://qt4cg.org/branch/master/xquery-40/xpath-40-diff.html#dt-static-error> is
> raised [err:XPST0017
> <https://qt4cg.org/branch/master/xquery-40/xpath-40-diff.html#ERRXPST0017>
> ]. For this purpose the number of arguments in the static function call
> is the number of positional arguments, plus one if there are one or more
> keyword arguments."
>
>
>  *Question*:
> This is true for array-variadic and record-variadic functions.
> For bounded variadic functions shouldn’t the number of arguments in the
> function call be M + N, where M is the number of positional arguments and N
> is the number of (all declared) keyword arguments?
>

I think this is left over from when the spec was just referring to
map-variadic functions. That is, the "plus one" is referring to the map
parameter as the last parameter of the function.


> *Quote*:
>
> "my:keyword-function(x:=3, y:=4) denotes a static function call with one
> argument: the effective value of the argument is map{'x':3,'y':4}."
>
> *Questions*:
> 1. Isn’t this statement true only for record-variadic functions?
>
> 2. keyword-function()  may even be non-variadic, just a function with two
> positional/required parameters and in this call the two positional
> arguments are supplied by keyword. In this case, shouldn’t the number of
> arguments be 2?
>
> 3. Shouldn’t the number of  arguments be 2 also for a bounded-variadic
> function?
> It is not  record-variadic or an array-variadic function.
>

I think this (and the fn:serialize example) are from an earlier draft that
just referred to map-variadic functions.


> *Quote*:
>
> "4.3.6 Static Functions
>
> %variadic("no") indicates that the function is not variadic. In a
> function call, an argument must be supplied for every parameter in the
> function signature. It can be supplied either positionally or by keyword,
> but there must be a one-to-one mapping between arguments and parameter
> declarations. The minimum and maximum arity are both defined by the
> number of parameter declarations."
>
> *Question*:
> Isn’t it more precise and clear to say that in this case both the minimum
> and maximum arity of the function have the same value, equal to the number
> of parameter declarations?
>

I think that makes sense, and could be written as compactly as the draft by
changing "are both defined by" to "are both equal to".


> *Quote*:
>
> "%variadic("bounded") indicates that the function is bounded-variadic. A
> bounded-variadic function declares zero or more required parameters and one
> or more optional parameters. In a function call, an argument must be
> supplied for every required parameter, and arguments may be supplied for
> optional parameters: in both cases, the argument may be supplied either
> positionally or by keyword"
>
> *Question*:
> Why is there no definition of what is the arity (minimum and maximum) of
> the function in this case?"
>
I think it would be useful to add a description of the minimum and maximum
bounds in this paragraph to be consistent with the others.


> *Quote*:
>
> "%variadic("sequence") indicates that the function is sequence-variadic.
> A sequence-variadic function declares one or more parameters, of which
> the last typically has an occurrence indicator of * or + to indicate that
> a sequence may be supplied.
>
>  *Questions*:
> 1. Why sequence-variadic and not array-variadic?
>
> If an array is used, then it can hold for example:
>     [1, (), 2, 3]
>
> and all 4 elements of the array will be accessible from the function
> call,  not just 3 as in the case when a sequence is passed:
>     (1, (), 2, 3)
>
> Thus having array-variadic functions (function calls) is more precise and
> expressive, as shown in this example.
>

In the "Variadic functions and dynamic function calls" thread, Michael Kay
explained that this is due to `[]` being ambiguous -- is it a single
argument to the variadic version and thus passed as `[ [] ]`, or is it the
value of the parameter itself? In that thread, I've proposed a
fn:function-arguments function as a way to get the array version of the
parameters if required:

    fn:function-arguments($from as xs:integer := 1, $to as xs:integer? :=
()) as array(*)
    (: This function is ·deterministic·, ·context-dependent·, and
·focus-independent·. :)


> 2. If the only reason is that fn:concat()  cannot be expressed/called as
> an array-variadic function, can we have both: array-variadic and
> sequence-variadic (the latter just for fn:concat() ) defined?
>

It can be expressed as either, however the value flattening for fn:concat
is more intuitive when defined as a sequence-variadic function. See the
explanation above.


> *Quote*:
> "%variadic("map") indicates that the function is map-variadic. A
> map-variadic function declares one or more parameters, of which the last
> must be a type that accepts a map .
>
> *Questions*:
> 1. Why not  “record-variadic”?
> Unlike the map type, the new record type allows for static typing (and if
> dynamic typing is really necessary, an “extended” record type may be used). Thus,
> using “record-variadic” will be an improvement over “map-variadic”.
>

Note that record types are not specifically a new type, but are a subtype
of maps (in that they provide additional constraints on maps). The current
draft text permits either map or record types, depending on whether or not
you want to restrict the values.


> 2. Is there any example of an existing standard function that cannot be
> expressed/called as a record-variadic function, but can be called as a
> map-variadic function?
>

I think it would be useful to define the map-variadic standard functions
using RecordTests, as that would permit static-time error checking.

I don't think we should be restricting this to how these are used in
standard functions (otherwise you end up with a situation like with
annotations where users can add their own annotations, but the language
doesn't provide mechanisms to take advantage of them without vendor
extensions/functions). For example, someone could create a json-object
function that is map-variadic as it can take any parameters. -- Given
Michael Kay's comments about someone not being able to find an array
function, it may be useful to add an fn:array and fn:map function, in which
case that would be an example of a map-variadic function that cannot use a
RecordTest.


> *General question*:
> In the case when a function call can be array-variadic or record-variadic,
> the caller may prefer to pass just one array (or a record) containing the
> variadic arguments. In this case wouldn't it be good to allow the ability
> to specify as a keyword argument this array (or record) and have a standard
> name for these (for example "varargs")? I believe this will improve the
> readability of the code.
>
My reading of the %variadic annotation is that it is an infered annotation
that depends on how the function is declared, and is a way of adding a new
property to functions without modifying the data model. Otherwise, the
statement "%variadic, which is present on all static functions" would not
make sense. -- It may be worth noting how the default value is calculated,
like is done with %public/%private. (This also implies that you could turn
off variadic behaviour by adding %variadic("no") to a function that would
otherwise be variadic.)

The intention is to have this be automatic, so a varargs or similar keyword
should not be needed. For sequence-variadic functions, a possible syntax of
`ItemType...`/`SequenceType...` has been discussed in other threads and the
variadic arguments proposal in the xpath-ng project.

Kind regards,
Reece

Thanks in advance for any answers and explanations,
>
> Dimitre
>
> P.S. A pdf version of this message is attached in case it isn't
> well-readable from the W3 web server.
>
> On Fri, Dec 11, 2020 at 9:52 AM Michael Kay <mike@saxonica.com> wrote:
>
>> I've posted a new draft for XPath 4.0 at
>>
>> https://qt4cg.org/branch/master/xquery-40/xpath-40-diff.html
>>
>> This include first attempts to draft spec prose for variadic function
>> calls, and for applying the lookup operator to atomic values as suggested
>> by Liam (current-date()?year syntax).
>>
>> 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.
>
>