- From: Dimitre Novatchev <dnovatchev@gmail.com>
- Date: Sun, 13 Dec 2020 13:07:23 -0800
- To: Reece Dunn <msclrhd@googlemail.com>
- Cc: Michael Kay <mike@saxonica.com>, public-xslt-40@w3.org
- Message-ID: <CAK4KnZd9sLH11FKpcvK4yKHov4H8H4bJwYu5_qPDgQKSskzUgw@mail.gmail.com>
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.
Received on Sunday, 13 December 2020 21:07:51 UTC