Re: QT4 CG Meeting 004 Agenda 2022-09-27

On Sun, 25 Sept 2022 at 19:24, Michael Kay <mike@saxonica.com> wrote:

>
> >
> >    2.3.1. Variadic functions
> >
> >   Dimitre proposes that we should discuss variadic functions sooner
> rather
> >   than later:
> >
> >     “WRT our dependency sorting, can we discuss with high priority and
> >     approve the XPath 4.0 variadic functions, so that immediately after
> that
> >     we could typically describe not N overloads of a proposed function,
> but
> >     just a single signature containing keyword arguments with defaults?”
> >
>
> Please take the time to carefully read and comment on section 4.4
> (Functions) in the draft XPath 4.0 spec
>
> https://qt4cg.org/specifications/xquery-40/xpath-40-diff.html
>
> There's quite a lot of complexity here and I suspect a thorough review
> will take more than one meeting.
>
> There's certainly something to be said for agreeing foundational material
> like this before we consider the design of specific functions that can take
> advantage of it. On the other hand, there's also a bit of a risk of getting
> bogged down...
>

I'm happy for this to be next, once we've gone through the list of
functions (especially those that are sufficiently stable for review).

I have an implementation of variadic functions in my XQuery IntelliJ
Plugin. From this, I've raised several issues...

1. #54 [XPath] [XQuery] Keyword arguments don't work with all
parameters/keys in static functions.
<https://github.com/qt4cg/qtspecs/issues/54> -- Extend KeywordArgument to
support EQNames (for QName parameters) and StringLiterals (for map keys
with spaces). This issue defines the semantics for both of these for
non/bounded-variadic and map-variadic functions.

Note: I have not yet supported this in my plugin.

2. #64  [XPath] [XQuery] Add a syntax for specifying optional parameters to
create bounded variadic functions.
<https://github.com/qt4cg/qtspecs/issues/64> -- This outlines a possible
syntax and semantics. It contains the list of functions that have default
arguments and what those defaults are.

Note: I've experimented with implementing the syntax, but have not
experimented with the semantics for these. The semantics of this for
constant values (numeric literals, string literals, function references) is
straightforward. The tricky parts here are the functions that have the
context item as the default value (`.`, e.g. fn:local-name) and fn:key that
uses `/` as the default value -- this is because those parts are evaluated
at the point at which the function is called, not the point at which it is
declared.

Note: In the comments, I've drafted an approach (that I've called design 2)
that I'm happy with for dealing with those tricky parts. The gist is to
create a DefaultExpr syntax allowing `:= default { . }` and `default { / }`
to be used respectively. I've sketched out the high-level semantics for
this in that comment. -- I'm happy to move the `DefaultExpr` part to a
separate issue if that makes it easier to review.

3. #67 [XPath] [XQuery] Allow optional parameters and keyword arguments on
map and sequence variadic functions.
<https://github.com/qt4cg/qtspecs/issues/67> -- This makes changes to the
proposed arity logic and argument to parameter mapping (Evaluating Static
Function Calls) that address some issues (outlined at the start of the
issue) with the current draft.

Note: This accounts for optional parameters in the arity calculations for
determining bounded variadic functions, but does not define how those are
evaluated -- that is discussed in issue #64 above.

Note: I'm confident in the changes here as this is the logic I've used in
my plugin.

4. #69 [XSLT] Built-in function changes to support default values
<https://github.com/qt4cg/qtspecs/issues/69> -- This modifies the functions
in the XSLT spec that have default values that are currently non-optional
(e.g. xs:string instead of xs:string*) to be optional. This includes
proposed text changes to define how passing an empty sequence to those
parameters will use the default behaviour. -- This then allows these
parameters to use `:= ()` as their default values instead of having some
complicated default logic.

5. #70 [FO] Built-in function changes to support default values
<https://github.com/qt4cg/qtspecs/issues/70> -- This is the same as #69,
but for the XQFO specification.

Note: I've not made the signature changes for these functions in my plugin,
nor do I have an implementation of the proposed behavioural changes. I
don't see there being any issues with these as the wording is adapted from
the existing specification rules.

Kind regards,
Reece