Re: New XPath draft

On Sun, Dec 13, 2020 at 12:20 PM Reece Dunn <msclrhd@googlemail.com> wrote:

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

If so, then this should be fixed.


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

If so, then this should be fixed.


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

So we both are in agreement!


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

Yes, we both agree on this!


>
>
>> *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·. :)
>

Actually, there isn't any ambiguity:

[ [] ]     is an array with a single item in it, which is the empty array
(arrays in this respect are different from sequences and do not
remove/flatten their empty items),
while [] is the empty array (containing 0 items).

This can easily be confirmed. Evaluating this:

let $ar := array { array {} }
  return Q{http://www.w3.org/2005/xpath-functions/array}size($ar)

 results in: 1

Evaluating this:

let $ar := array { }
  return Q{http://www.w3.org/2005/xpath-functions/array}size($ar)

results in: 0

*Conclusion*: There is no ambiguity between [ [] ]   and   []


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

As per the conclusion above,  that actually there is no ambiguity, a call
to fn:concat() cannot be expressed as an array-variadic call. I suspect
that this is the only standard function with this problem.
Therefore the raised question remains valid and needs an answer.


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

Following this logic one can say that both: the record type and the map
type are examples of the function type. Then why not call all these
"function-variadic"? :)
We have the chance to use a most precise name, and this is
"record-variadic", unless someone can show an example of a standard
function that can be called as "map-variadic" (passing a map) but not as a
record-variadic (passing a record).

So, this question still needs a definite answer.



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

Exactly, and this is why we should give it the precise name:
"record-variadic"!


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

Sorry, you lost me here :(


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

I never said that naming the last argument was "needed". Just that using a
standard name for it will increase the readability of the code, when the
function call provides the complete array or record as the single last
argument.



>
> Kind regards,
> Reece
>

Thanks Reece,

Dimitre




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

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