QT4 CG Meeting 004 Minutes 2022-09-27

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?”

• CSM: I think we should talk about it, but I doubt we’re ready to make a decision. Mostly, at the moment, I want to raise a deeper question: are we sure we want to do this? I’m nervous because there was a time when the QT WGs had multiple people who spent their careers doing type theory, and we didn’t do it then. Are we sure we have the necessary experience to avoid the pitfalls?
• RD: I do have a working implementation of the variadic function calls, mapping function arguments to function parameters. That’s implementing the current spec plus one the issues that I raised around that…# (separating the variadic type from …)
• MK: I think caution is absolutely justified. It occurred to me this morning, trying to do my revised way of presenting the design, that one thing that’s badly lacking so far is the substitutability rules. Let’s go back to why we’re trying to do this?
  • The primary aim is to make the functions we already have more extensible. Doing it by always adding more isn’t always what you want.
  • The “options map” option was introduced in 3.1 and a lot of folks think that could be more useful with keyword parameters.
  • There are good motivations for wanting to do it, but I share CSM’s concern about the potential complexity. We fell into type theory traps in 3.1 and we have bugs in the spec.
• JL: Do you have an example?
• MK: Yes, I forget exactly where it is, but we talk about the type of a map when considered as a function and we talk about having the “least common type” of two types, and that phrase is used glibly without realizing that our type system doesn’t have that concept.
• JL: The hardest thing I recall in the later stages of SaxonJS was substituting functions. Everything gets turned upside down and adding variadic seems really tricky.
• RD: In terms of named keywords, one of the cases where that is useful is if you have three or four boolean parameters. Having names allows you to know exactly which things are “true”, “true”, and “false” for example. Constructing a map and passing it into a function call can be complicated where passing them on the function would be easy.
• CSM: Sanity check, I think based on my reading of the proposal, that if I have three parameters all of them declared single, booleans. I can use their parameter names as keywords: a=true, b=true, c=false, in whatever order is rhetorically best at the point of call. I haven’t quite got my head around optionality and keyword parameters.
• MK: I think optional parameters are relatively low risk. It’s the truely variadic ones that create potential complexity.
• RD: That’s the ones that bind a sequence to a set of parameters…
• MK: Yes.
• DM: I think this proposal stemmed from a conversation that I had with Mike in chat. I was thinking only keyword parameters, which seem low risk. We should focus on the challenging things.
  • The benefits of having this as early as possible in our process is very large. This can lead to significant simplification of the documents. We can avoid the need to have many different function signatures.
• RD: I wonder if it makes sense to divide this up a bit, rather than tackling all at once.
  • The initial goal that DN brought this up for was specifying default parameters on functions to reduce the complexity in the F&O spec. That would require bounded variadic functions which keep the functionality between an upper- and lower-bound with specified defaults.
  • And we could allow keyword arguments.
• I don’t think that adds anything to the type system. At some point in the future, we can look at how to apply these to sequence types and map types.
• NW: If we can decompose the problem into smaller pieces, that’s a good thing.
• MK: That sounds like a good idea to me.
• RD: We can always add things in the future.
• MK: One question, particularly of Dimitre. Do we want keyword parameters on dynamic function calls?
• DN: I think that’s an extremely good question. It only matters if we define a dynamic function and then we have a large scope where we use that function. If there are a lot of calls to that function, then it would be helpful to users. I’m not ready to say “yes” very firmly, but I do see use cases where it can be useful.
• MK: I think its a lot more difficult to define things like partial function application if we need to do it in the dynamic case.

• MK: The terms appear not in my email of this morning, but in the original proposal. In this morning’s proposal, I attributed a plurality to each of the arguments. A bounded variadic function is basically one that has single and optional arguments, but doesn’t have multiples or maps.
• JL: Is concat the only function we have with multiple, unbounded arguments?
• RD: That’s the only one in the spec, but other implementors have tried to generalize the idea in other functions. BaseX out-format is variadic, so is allow, and the XQuery rest-consumes, etc… Various MarkLogic functions are also variadic.
• MK: In this area, it’s an awful lot easier to do something in an implementation than it is in a specification.
• NW: Does it make sense to come back with new drafts for just the parts
• JK: Much of the proposal is written from the perspective parsing and understanding a function. It would be nice to have some discussion of whether or not function authors are going to have to think about things differently.
• MK: In a lot of existing function libraries, there’s some possibility that users will discover that they wish they’d chosen better names. Those are now going to be public where they’d previously been private.
• RD: The way the draft is currently specified, function authors won’t have to change the order of things to make things variadic. Variadicness applies to the last argument. If the last parameter is a map, you can use the map keys. If the last parameter is a sequence, you can zero or one or more arguemnts.
• CSM: I think we now have two examples of the utility of what JK suggests. Correct me if I’m wrong, you’re not limited to a single map or multiple parameters. That’s the idiom I’m familiar with, but in the proposal before us, the only constraint is that if I have more than multiple/map; if I want to reach any of them except the first declared, I have to use keyword. But if I use keywords, I can have an arbitrary number of them.
• MK: No, that’s not quite the proposal. In the language of this mornings proposal, you can have zero or one multiple parameters and zero or one mapped parameters. You can have zero or more single or optional parameters.
• CSM: Thank you. I just misread the paragraph.
• RD: I’m basing my comments on the proposal that’s actually in the current spec; I’ve only read MK’s proposal briefly. It would be good to have a more formal proposal.
• DN: I’ve missed this morning’s proposal, but can I propose that at first we concentrate on adding variadic bounded functions. I think that’s an easier case.

ACTION QT4CG-004-01: MK (with DN and RD) to draft a new proposal for variadic functions

Dimitre observes “some of the functions to be discussed that are included in the current list/checklist, depend on using a compare() function / strategy. This makes all of them dependent on having first discussed and approved fn:deep-equal(options). Therefore, could we move fn:deep-equal(options) considerably higher in the list, so that it precedes all such functions that are dependent on a compare() function/strategy?”

• DN: There are a number of functions higher in the list that can take different kinds of comparisons (sequence starts with, contains, etc.) They can use different comparison functions. While we can generally say that people can specify any comparison function they want, MK and I discussed a lot about what could be a good comparison function.
  • It seems like some options on fn:deep-equal could be a good way to go to reach consensus on such a function.
• MK: I have no objection to working on deep-equal sooner, but we don’t have a proposal to discuss at the moment.
• DN: This is related to allowing any items as keys of maps. I constructed deep-equal-safe in the comments to this proposal. That could possibly be regarded as a starting point.

ACTION QT4CG-004-02: DN to make a proposal for deep-equal-safe for future discussion

• MK: I’d like to look at the order of the functions on the agenda; some have fairly well formulated proposals, we should start with those.

MK proposes starting with fn:intersperse.

No objections.

• See https://github.com/qt4cg/qtspecs/issues/2
• MK: I think it would be useful to show a sample implementation for a bit more rigorous definition. There are a couple in the comment.
• CSM: I’m not sure I understand the function. We have examples of how to call it, but I don’t see an explicit statement of what gets return. The analogy with string-join makes me nervous.
• DN: The separator can be any sequence, not just an item.
• DN: I have a question about the name, intersperse carries connotations of randomness.
• MK: If it’s in other languages, that’s good enough.
• CG: It’s in Haskell and Dart.
• DN: What about the reverse? Splitting on a sequence?
• RD: It’s more like “take ‘n’ drop ‘k’ repeat.”
• CSM: I like, in general, the idea of having an inverse if you can specify it.

Chair interrupts the discussion of the inverse function to get clarity on the proposal.

Proposal: Accept fn:intersperse

No objections.

ACTION QT4CG-004-03: MK to draft a pull request implementing fn:intersperse

• RD: I think it’s straightfoward to implement the inverse because you’re applying a collect to collect one plus the number of interspersed items.
• NW: That’s more clever than I am…
• CSM: You have to check that the ones you’re removing match the thing that was inserted.
• RD: It would have to be that you can’t do anything between intersperse and the inverse, otherwise you’re going to tie yourself into knots.
• NW: It seems more like a “split on matching subsequences” function to me, and how does the result get returned anyway, given that we don’t have sequences of sequences?
• DN: It could return it in an array and we probably need an analogous function to intersperse arrays.
• JK: I think the inverse function might get really complicated with exceptions and error handling. The analogy to string-join is helpful here, the inverse would be like tokenize.
• CG: I was wondering if we have a practical use case for such a function, there’s nothing like this in Haskell and Dart.
• DN: Consider the case where a function takes a single string and the first thing the function does is tokenize that string. Similar use cases probably exist for this function.
• RD: Would CSV parsing be a use ase? Tokenize on newlines and…

With time running short, the chair proposes that DN take an action.

ACTION QT4CG-004-04: DN to open an issue for the inverse of fn:intersperse