QT4 CG Meeting 148 Minutes 2026-01-13

Regrets: EP.

• [X] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [ ] Sasha Frisov (SF)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Dimitre Novatchev
• [X] Alan Painter (AP
• [X] Wendell Piez (WP)
• [ ] Ruvim Pinka (RP)
• [X] Liam Quin (LQ)
• [X] Norm Tovey-Walsh (NW) Scribe. Chair.

Proposal: Accept the agenda.

Accepted.

Proposal: Accept the minutes of the previous meeting.

Accepted.

The next meeting is planned for 20 January 2026.

JWL gives regrets for 20, 27 January.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-143-03: JK to look for C14N test suites.
• [ ] QT4CG-144-01: MK to consider if any now lost value comparisons should be added as examples.
• [X] QT4CG-147-01: MK to fix the change markup entry for fn:curent-merge-group; it refers to the wrong function name.
• [X] QT4CG-147-02: NW to chase up DN and LQ about follow-up to the generator discussion

This section summarizes all of the issues and pull requests that need to be resolved before we can finish. See Technical Agenda below for the focus of this meeting.

See PR #2350.

Thanks to DN and LQ for providing more use cases in email.

MK introduces his proposal.

• MK: I’ve used the phrase “incremental evaluation” for this topic; I didn’t want to use “lazy evaluation” because that’s a broader topic.
  • … This is about functions and expressions that operate on a sequence one item at a time.
• MK: It should work on sequences and arrays; I haven’t done the work on arrays yet.
• MK: I divided functions into categories based on whether they can consume or produce infinite sequences.
• MK: We define a fn:generate function.

MK walks through the examples in the spec.

• JLO: Very interesting. This looks very promising because it’s just one function.
  • … In the example with the random number generator, there’s a parenthesis missing in the funtion call.
• RD: When deciding whether functions can accept unbounded sequences, are we going to try to do that with a set of properties?
• MK: Yes, I was thinking of doing it that way.
• DN: Thank you for this proposal. It’s always good to have alternatives. Our highest priority should be the user; more than who makes the proposal, and more than what is convenient for the implementors.
  • … General impression is that this proposal is incomplete.
  • … Conceptually it’s fragmented and lacking a unifying extraction.
  • … Compared to original proposal, I think it’s difficult to understand
  • … Forces sequence-valued yields to be encoded indirectly.
  • … Lacks composibility
  • … Lacks construction based on external providers
  • … Too “implementation-defined”
  • … In brief: it violates the principle of making things as simple as possible, but no simpler.

DN goes into more detail about these points…

• DN: It doesn’t define a formal evaluation model, composition rules, external data integration, or observable semantics.
  • … It’s incomplete for a language-level abstraction.
• DN: The proposal mixes terminology, categores, gaurantees, advice, core semantics, and warnings.
  • … Hard to build a mental model, hard to reason compositionally, hard to teach
• DN: Very difficult to understand compared to original.
  • … The original proposal defines just one abstraction and defines it fully. It shows you how everything builds on it.
  • … The MK proposal shifts complexity from the implementor to the user
• DN: Forces sequence-value yields to be encoded indirectly
  • … The fn:generate() returns item()*
  • … An item cannot be a sequence.
  • … Theref ro eacy yield-value is only an item
  • … There are work arounds: arrays, maps, etc. But these are encodings not first class semantics.
• DN: Lacks composibility
  • … In MK’s proposal, composability depends on which functions happen to be incrementally implemented
  • … Gaurantees are selective and asymmetric
  • … No type-level of semantic gurantee of streaming composition
  • … In the original proposal, every generator-consuming function composes.
• DN: Lacks construction based on external providers
  • … It’s purely functional, it assumes internal state progression, it cannot safely represent sockets, cursors, feeds, backpressionr, etc.
• DN: Too implementation-defined / questionable portability
  • … The proposal relyes on “may or may not”, “implementation-dependent”, “not mandated”, “outside the scope”…
  • … This is not acceptable for correctness, termination, and resource safety.
• DN: Make it as simple as possible, but not simpler
  • … That’s not rhetoric, it’s accurate.
  • … the MK proposal removes abstraction, pushes complexity onto users and implementations, leaves behavior unspecified.
• DN: The alternative proposal is incomplete and conceptually fragmented
  • … It’s difficult to reason about. It lacks a unifying abstraction, doesn’t support external data providers, and requires each yield-value to be a single XPath item.
  • … It shifts complexity into user code.
• LQ: I understood the proposal much better after today’s presentation.
  • … I don’t think it’s an either-or at this point; DN’s generators proposal is slightly higher-level, but could still be built on this.
  • … I don’t think it’s true that you can’t have a function that does external things. But you’d need room in the generator record to have more space to hold things.
  • … Bringing it into the language instead of having a separate library is a great step forward, but the higher level stuff needs a bit more work.
• JK: Thanks for the work everyone has put into this. For the PR on the table now, it strikes me as falling into two parts: the conceptual model of processing, that could be spun off profitably. The second half is the generator itself, that struck me as a somewhat trivial example. As a user, when I think about a generator, my first thought is about the random number generator. I’ve got a set of expectations based up on that, that there’s a next and stepping that I’m in control of. That’s missing from the fn:generator function. I don’t find this proposal compelling.
• RD: One of the key advantages of this is that the result is an XPath sequence, so you can do things like filter expressions, etc. without any additional machinery. If you’ve got a function that operates on a sequence, you can call it irrespective of whether the sequence is a range or a generator.
  • … Currently, if you’re using the randon number generator and you want to work out the average, you’d have to hand code that. But you could leverage the existing function with fn:generator.
  • … Semantically, both of these proposals are in effect two different views of the same concept. DN’s is explicit exposing an interator model whereas this proposal is wrapping that machinery within the XPath semantics. I don’t see the two as being incompatible.
  • … We could take DN’s functions and use those to infer which XPath functions are processable with a generator.
• DN: I have two more observations.
  • … There’s no formal equivalent for the fn:generate function, but there are for the original proposal.
  • … Saying you can’t use distinct values with an infinite sequence isn’t quite right, you can ask for the first three distinct values, for example.
  • … I think the generator type is more expressive. The move-next function for example is part of the state; it can specify a different move-next function for the next generator.
  • … Users want to be in control.
• CG: I agree with LQ, I think both the fn:generate function and the generator record could both be interesting for users. I noticed that fn:generate is easy to implement if your implementation supports iterators. Our team found it intuitive, but the generator record concept from before was much more difficult to understand.
  • … Hakell has something called “unfold” that’s similar to the generator function. I see many simple use cases where this function can be used, but with more complex scenarios you might need generator records.
  • … We have concrete examples for the fn:generate function, but we still don’t have concrete examples for the generator records.
• JLO: I like the simplicity of fn:generate. I like the control that a generator record would give us. I fear we’ll end up in a swamp of deciding how each function should behave.
• NW: Let’s leave this for a week or two. We got some examples and use cases in the last 24 hours or so. Let’s see if we can have some more discussion and make progress.
• DN: I provoded a few hundred tests, so I don’t think it’s more work. It’s all there and already working. We have to think about users!

See issue #2351.

Last week, we discussed creating a dated, checkpoint draft. CG suggests we review this issue first.

• NW: Are we ready to cut a dated release?
• CG: Are we going to cut some things? We should try to do that before the draft.
  • … The syntactic sugar for filtering maps and arrays
  • … Functions related to maps and arrays.
• MK: Working groups sometimes mark features as “at risk” because the WG expects them to change. We could try that.
• JWL: On the filtering, I thought the case for removing the syntactic sugar was moderately strong. But it’s not a hill I’m going to die on.
• JLO: I’d propose that we mark the things that are stable.
• NW: I think that’s too hard.

Some discussion seems to lead to consensus for marking the syntactic sugar and the array functions as “at risk”.

• JWL: If you’re going to put at risk in, you’ll need to mention it right at the top.

ACTION QT4CG-148-01: NW to draft a PR that marks #2351 items as “at risk” with appropriate definitions at the top of the document

Proposal: Take a dated draft at that point?

Accepted.

ACTION QT4CG-148-02: NW to publish a dated drafter after QT4CG-148-01 is complete.

See PR #2313.

• CG: I think it’s a good solution for the first case, I’m not sure about the second case.
• RD: In the grammar we have things that we put in comments: whether it’s whitespace signficant or not. Could we have a comment with a note that points to the rule.
  • … Just make the comment “note” that points to the rule.
• JWL: It was the “=” I didn’t really like.

ACTION QT4CG-148-03: NW to revise his attempt at #2313 by using the text “node” and a link to the appropriate text