QT4CG meeting 145 draft minutes, 9 December 2025

Hello,

Here are the minutes from today’s meeting:

   https://qt4cg.org/meeting/minutes/2025/12-09.html

QT4 CG Meeting 145 Minutes 2025-12-09

   [1]Meeting index / [2]QT4CG.org / [3]Dashboard / [4]GH Issues / [5]GH
   Pull Requests

Table of Contents

     * [6]Draft Minutes
     * [7]Summary of new and continuing actions [0/5]
     * [8]1. Administrivia
          + [9]1.1. Roll call [15/15]
          + [10]1.2. Accept the agenda
          + [11]1.3. Approve minutes of the previous meeting
          + [12]1.4. Next meeting
          + [13]1.5. Review of open action items [0/5]
          + [14]1.6. Review of open pull requests and issues
               o [15]1.6.1. Blocked
               o [16]1.6.2. Merge without discussion
     * [17]2. Technical agenda
          + [18]2.1. PR #2247: Deferred Evaluation in XPath - the
            f:generator record
     * [19]3. Any other business

Draft Minutes

Summary of new and continuing actions [0/5]

     * [ ] QT4CG-143-01: CG to make another attempt at binary functions.
     * [ ] 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.
     * [ ] QT4CG-144-02: MK to add notes about edge cases: sequence
       normalization and character maps for example.

1. Administrivia

1.1. Roll call [15/15]

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

1.2. Accept the agenda

   Proposal: Accept [20]the agenda.

   Accepted.

1.3. Approve minutes of the previous meeting

   Proposal: Accept [21]the minutes of the previous meeting.

   Accepted.

1.4. Next meeting

   The next meeting is planned for 16 December 2025.

   Regets: SF, RD

   After next week, the CG will recess for the end-of-year holidays. The
   following meeting will be on 6 January 2026.

1.5. Review of open action items [0/5]

     * [ ] QT4CG-143-01: CG to make another attempt at binary functions.
     * [ ] 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.
     * [ ] QT4CG-144-02: MK to add notes about edge cases: sequence
       normalization and character maps for example.

1.6. Review of open pull requests and issues

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

1.6.1. Blocked

   The following PRs are open but have merge conflicts or comments which
   suggest they aren't ready for action.
     * PR [23]#2160: 2073 data model changes for JNodes and Sequences
     * PR [24]#2124: 573 Functions to Construct Trees
     * PR [25]#2071: 77c deep update
     * PR [26]#2019: 1776: XSLT template rules for maps and array

1.6.2. Merge without discussion

   The following PRs are editorial, small, or otherwise appeared to be
   uncontroversial when the agenda was prepared. The chairs propose that
   these can be merged without discussion. If you think discussion is
   necessary, please say so.
     * PR [27]#2332: 2195 Misc XSLT editorial fixes
     * PR [28]#2331: 2330 In XSLT Patterns, allow Constants rather than
       Literals
     * PR [29]#2328: 2326 Expand spec of new `cdata` attribute

   Proposal: merge without discussion.

   Accepted.

2. Technical agenda

2.1. PR #2247: Deferred Evaluation in XPath - the f:generator record

   See PR [30]#2247.

   DN begins by reviewing the Deferred Evaluation section of the PR.
     * DN: Most useful in cases where it's impossible or impractical to
       materialize an entire sequence in memory.
          + ... Huge thank you to all the people who supported this work:
            AP, LQ, Ken Holman, SF, Adam Retter, Andy Bunce, and [31]Kurt
            Cagle, many of whom expressed enthusiastic support for the
            work.
     * DN: The generator is a way of implementing an iterator.

   DN reviews the description of the generator record in the spec.
     * NW: Before we get too deep into the details, does LQ have any
       opening remarks?
     * LQ: I [32]sent some notes to the mailing list.
          + ... Lots of people want to do this and it's a bit tricky to
            write.
          + ... If something is a little tricky to write, you'll get
            interoperability problems
          + ... It's great to have it readily available.
          + ... MK asked about how this relates to XML/XPath/XSLT/XQuery,
            etc. "There weren't enough X's in the proposal."
          + ... It's sometimes hard to demonstrate some of these things in
            a small space.
          + ... A good comparison is with xsl:iterate in XSLT. Before
            xsl:iterate, you had to do everything with recursive
            functions. And that's tricky if you don't understand tail-call
            optimization.
          + ... Writing this stuff was quite difficult. It got easier as
            implementations improved tail-recursion implementations.
          + ... The xsl:iterate instruction forces you to write something
            that can be tail-optimized.
          + ... When I asked the XSL mailing list, xsl:iterate was very
            popular, second only to expand-text.
          + ... Generators will be like expand-text; they'll make lots of
            things easier to read.
          + ... There's nothing in xsl:iterate that you couldn't write
            yourself. You could write fn:replace yourself, too, if you
            wanted to.
          + ... The right question isn't "what does this let people do
            that they couldn't do before"
          + ... The right question is "what will they do with it that they
            wouldn't have done without it."

   LQ describes [33]his use case (see email).
     * LQ: The book lookup case is an example of lazy evaluation. And
       that's what generators give us. They let us write in a stereotyped
       way that would be too expensive if you did all of it, and you know
       you don't need to do all of it, but you don't know how much you
       need to do.
          + ... You can't download from the British Library, you use an
            API, and you can't do them all through that API, that would be
            a denial of service attack!
     * LQ: The business case I have is a text similarity case. It's
       expensive to do similarity testing. If you have a 1,000 paragraphs,
       you might have a million pairs. But you can find candidates with
       structural information. That reduces it to a few hundred. We want
       to take the first few and the move on to the next case.
          + ... The point is that it's less to write than a template or
            function, and it's in a very common style. Like Javascript's
            ?. operator.
     * LQ: Things that are good for standardization are things many people
       have to write themselves, that they tend to write incorrectly, that
       are just hard enough to do that people will walk away if its not
       available, and things that extend the reach fo the language.
     * RD: One main example of a protoype of this is the random number
       generator function. Currently in the language, that's very hard to
       work with. Having some infrastructure to make working with that
       easier is a win. Also, this allows you to write other things like a
       Fibonacci number generator.
     * SF: In other languages, generators have been introduced as their
       own state machine. These coexist with other parts of the system. If
       you have your own state machine (Fibonacci numbers or decomposing a
       problem into parts), that makes some problems very easy to write in
       imperative languages, but much harder in functional languages.
       Introducing generators opens the ability to solve these sorts of
       problems.
          + ... Iterators, signals, events, etc. It's an opportunity for
            coordination across state machines.
          + ... These steps can then feed things back.
     * SF: I hear MK when he asks about whether it feeds into XSLT. Yes
       and no, it allows multithreading and multiprocessing to be mixed
       with procedural programming. That's not exactly what XSLT does, but
       it simplifies the code.
     * CG: Thanks DN and LQ, for the presentation and the PDF file. I see
       that you've mentioned the while-do function. One reason we
       introduced this function was to deal with potentially unlimited
       results. I was wondering if you've thought of simple examples that
       cannot be realized with while-do or are much harder without
       generators.
     * RD: It's more about feeding this into other things and chaining.
       The while-do function has the logic in the callback function. But
       if you wanted to take a list of Fibonacci numbers and in one case
       you want to multiple them and in another case you want to take the
       differences, you have to write the Fibonacci logic and tracking in
       both loops.
     * DN: Many of the generator functions are inspired by the while-do
       function.
     * JL: This is really interesting. I'm a big proponent of putting
       generators in XQuery. I think RD is right that the random number
       generator is a generator. It would be easier for people to use if
       they had more infrastructure.
          + ... I'd like to know why did you decide to go with a move-next
            method call instead of something like the yield keyword?
     * DN: The short answer is that introducing yield would necessitate
       changes in the languages that I wanted to avoid. We can do this
       step by step.
          + ... There's also feedback from C# and other places that
            suggests that yield makes it harder to understand what is
            happening.
     * MK: Two kinds of comment:
          + ... About planning, I'm concerned about the size of the
            proposal and how much work still needs doing (It has improved
            a lot! Thank you!)
          + ... I look back on past projects of similar size and consider
            how long they actually took.
          + ... In a slightly orthogonal way, it's great to see the number
            of people we have active in this group. A project manager once
            told me there are good starters and good finishers. And in
            this kind of activity, we have to worry about good finishers.
            I'm concerned about that in terms of working group dynamics.
          + ... The other concern I have is a sort of feeling that it
            could be much smaller. I'd be able to answer that more
            clearly, if I had three or four worked out use cases using
            generators laid out in front of me. Then I could compare.
            That's an appeal to do more work on use cases.
     * AP: I wanted to second what MK said about the use cases. I think
       that would be very useful. DN and I were working on the slice
       function and there was a bit of a missmatch there.
          + ... I also have a gut feeling that things could be simplified
            a bit. Maybe it could be a library module? Maybe we could have
            a separate definition for generators.
     * JWL: Very similar. I got three senses: the generator, the
       "necessary" or "most preferable" functions, and then you've got a
       lot of other functions that sit on top of it. What is the essense
       that needs to be implemented deep down to get performance or the
       right kinds of outputs.
     * JK: I support the idea of generators. I feel the pain of
       implementors. As a point of suggestion on how to bridge this gap, I
       recommend the authors take a more real world example with an
       infinite amount of XML. I think that would help.
     * NW: Are you guys willing to provide three or four substantial
       worked up use cases?

   LQ and DN seem generally willing.
     * CG: I would also be interested in exploring the exising XQuery
       implementation and if there are core features that would make it
       run more quickly, I'd be interested in that.
     * DN: There's a pure XQuery implementation:
       [34]https://github.com/dnovatchev/Articles/blob/main/Generators/Cod
       e/generator.xq
          + ... I think trying that out would be very useful. It might be
            possible for people to make their own use cases.

   We'll return to this PR in a few weeks when use cases have been
   produced and reviewed.

3. Any other business

     * NW: Enjoy the holidays and happy New Year to anyone we won't see
       next week!

References

   1. https://qt4cg.org/meeting/minutes/
   2. https://qt4cg.org/
   3. https://qt4cg.org/dashboard
   4. https://github.com/qt4cg/qtspecs/issues
   5. https://github.com/qt4cg/qtspecs/pulls
   6. https://qt4cg.org/meeting/minutes/2025/12-09.html#minutes
   7. https://qt4cg.org/meeting/minutes/2025/12-09.html#new-actions
   8. https://qt4cg.org/meeting/minutes/2025/12-09.html#administrivia
   9. https://qt4cg.org/meeting/minutes/2025/12-09.html#roll-call
  10. https://qt4cg.org/meeting/minutes/2025/12-09.html#agenda
  11. https://qt4cg.org/meeting/minutes/2025/12-09.html#approve-minutes
  12. https://qt4cg.org/meeting/minutes/2025/12-09.html#next-meeting
  13. https://qt4cg.org/meeting/minutes/2025/12-09.html#open-actions
  14. https://qt4cg.org/meeting/minutes/2025/12-09.html#open-pull-requests
  15. https://qt4cg.org/meeting/minutes/2025/12-09.html#blocked
  16. https://qt4cg.org/meeting/minutes/2025/12-09.html#merge-without-discussion
  17. https://qt4cg.org/meeting/minutes/2025/12-09.html#technical-agenda
  18. https://qt4cg.org/meeting/minutes/2025/12-09.html#pr-2247
  19. https://qt4cg.org/meeting/minutes/2025/12-09.html#any-other-business
  20. https://qt4cg.org/meeting/agenda/2025/12-09.html
  21. https://qt4cg.org/meeting/minutes/2025/12-02.html
  22. https://qt4cg.org/meeting/minutes/2025/12-09.html#technical-agenda
  23. https://qt4cg.org/dashboard/#pr-2160
  24. https://qt4cg.org/dashboard/#pr-2124
  25. https://qt4cg.org/dashboard/#pr-2071
  26. https://qt4cg.org/dashboard/#pr-2019
  27. https://qt4cg.org/dashboard/#pr-2332
  28. https://qt4cg.org/dashboard/#pr-2331
  29. https://qt4cg.org/dashboard/#pr-2328
  30. https://qt4cg.org/dashboard/#pr-2247
  31. https://medium.com/@kurtcagle/this-is-fantastic-602d5bfb8405
  32. https://lists.w3.org/Archives/Public/public-xslt-40/2025Dec/0004.html
  33. https://lists.w3.org/Archives/Public/public-xslt-40/2025Dec/0004.html
  34. https://github.com/dnovatchev/Articles/blob/main/Generators/Code/generator.xq

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 9 December 2025 17:50:12 UTC