QT4 CG Meeting 183 Minutes 2026-10-06

• [X] David J Birnbaum (DB)
• [X] Reece Dunn (RD)
• [X] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK)
• [X] Michael Kay (MK)
• [X] Juri Leino (JLO)
• [X] John Lumley (JWL)
• [X] Alan Painter (AP)
• [ ] Ruvim Pinka (RP)
• [X] Wendell Piez (WP) [x:10-]
• [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 13 October.

No regrets heard.

• [ ] QT4CG-143-02: MK to try to recover the ability to extract formal equivalences into tests
• [ ] QT4CG-167-07: NW to review tests for interpolated strings with edge cases in mind
• [ ] QT4CG-167-09: NW to close all “nice to have” issues at the end of October if they haven’t progressed
• [ ] QT4CG-170-01: RD to draft a proposal that attempts to address the lexical issues differently.
• [ ] QT4CG-177-01: NW to put the progress graphs back in the minutes.
• [ ] QT4CG-182-01: NW to review CG’s diff script

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 #2966

• CG: This is probably a bit tricky to present. We had a BaseX bug with the multiline option and when I looked in the spec, I wasn’t sure what it said. And then I noticed a few other things.
  • … The issue has a long history going back at least a decade or more.
• CG: I have tried to clarify without making controversial changes.

CG reviews some of the examples and the updated rules.

• MK: I’d like to do further work on the PR before we merge it.
• CG: I could try for next week.
• MK: Or perhaps I could try.
• RD: Should the examples use the standard markup?
• MK: The example markup isn’t availble in a narrative section, unfortunately.
• JK: I’m interested to see how this goes. Is it getting too much into the implementation to try to define things like “current position”?
• MK: The problem is that we’ve inherited a lot of the specification from XSD and it doesn’t need a concept of current position. We’d have to redefine semantics for things like “$” in the middle of a string.
• RD: Would that definition be in line with things like state machine regular expressions?
• MK: I don’t think you have to do that, you just need a rephrasing for branches, choices, sequences, and those kinds of things.

See PR #2964

• MK: This is sort of editorial. It’s carrying forward a change that we made to the data model, explaining implications that might not have been apparent.
• MK: There’s a small change to the data model and more of a change to the casting rules.
• MK: In the Data Model, it’s just an update to the non-normative list of changes we apply to XSD.
• MK: In F&O, under 23 Casting, we now reference that as a change to the casting rules
  • … And we say that the semantics of casting are defined exclusively in terms of XSD 1.1.
• MK: It expands the note about the impact of canonical lexical representations.

(This all started as a bug against the test suite; a challenge to some of the results.)

• MK: I also discovered an ambiguity in the specification. In 23.3.6, I’ve added a note to clarify it.

Proposal: accept the PR.

Accepted.

See PR #2962

CG outlines the proposal:

• Drop fn:csv-to-arrays
• Many CVS strings have quotes in a field, that’s not something we can currently parse.
• CG: We resolve the quote problem by accepting quotes embedded in the field but not at the start at the field.
  • The quote character has no special meaning unless it occurs at the start of the field.
• JLO: This sounds very good. Does it have to be the first character after the comma, or is whitespace allowed?
• CG: You can’t have a space.
• JLO: I don’t think I like that. I think you should be allowed to have space.
• MK: If you don’t allow space, what is the value of the field. The space would be significant.
• JLO: Okay, then it’s fine.

Proposal: accept the PR.

Accepted.

See PR #2958

• MK: It’s primarily in XQuery and mirrored elsewhere.
• MK: It’s probaby best to start with the record declaration itself in the prolog.
  • … The grammar now allows you to define a field as %static
  • … I made the default for %constructor false, although CG would prefer true.
  • … I think the code is a bit more readable if you explicitly enable the constructor.
  • … We also don’t need or want constructors for our built in record types, so maybe that’s the right default.
• MK: Initializing expressions are now used not only as default values for the constructor function, but also in casting and coercion.
• MK: The %static string mimicks and annotation, but it’s not technically an annotation at the moment. You can’t put general annotations on fields.
• MK: We use the %constructor annotation to decide whether or not you get a constructor function.
• MK: The main change in how the constructor is defined is about how static fields are handled.

Returning to the beginning of the spec.

• MK: The coercion rules are now split between the two kinds of record type.
  • … For a structural record type, they are as they were.
  • … For a nominative record type, the static fields are always fixed.
• MK: The records are written so that coercing from a record to its own type won’t fail.
• MK: The casting rules change similarly.
• MK: XSLT has corresponding changes.
• RD: By default, a record declaration doesn’t generate a constructor. Because of that, I think it makes sense for the %constructor annotation to add the constructor. I don’t see the point of the boolean argument to it.
• MK: Yes, we could do that.
• JLO: That’s what I wanted to say. I think presence should be enough.
  • … When I declare record that doesn’t have a constructor, how do I create one?
• MK: By casting or coercion.
• CG: I think this is a good step forward. I would really prefer the default be to have a constructor.
  • … We use records quite a lot and everywhere I see them, we also use the constructor.
  • … It’s an exception that we don’t have them.
  • … In our experience, every record declaration would need the extra annotation.
• MK: It’s hard to pick a default until you have a lot of experience.
  • … I think part of it is that saying more should give you more and saying less should give you less.
  • … I didn’t want a %no-constructor annotation.
• RD: I’d be happy with declare record making a constructor and declare type not. That would make the difference clear.
• JLO: I thought we dropped declare record?
  • … No? Then I’d be happy with that distinction as well. I think most users will use %constructor.
• MK: There are several cases when you dont’ want a constructor:
  • … When it’s the return type of a custom function
  • … And where the record has semantics that are not just a collection of fields; you want to do some validation.
    • … You don’t want people to be able to construct the record just from its fields; you want a semantic constructor that enforces more constraints.
• CG: For the return type, you need go generate the record, so a constructor would be useful.
• MK: Yes, but you want the constructor to be private.

Proposal: accept the PR.

Accepted.

• MK: I agree that we should drop true/false in constructor
• CG: Is it like public and private?
• MK: No, it’s just presence or absence.
• RD: Public/private is useful for documentation purposes.
• JLO: Maybe having the %constructor will be useful to IDEs so they know that you can’t write a constructor.

MK will make the change and then merge this PR.

See PR #2949

• CG: I haven’t changed the PR, I added a note that we could think about renaming the functions.
• MK: Looking at examples of subsequence-where doesn’t make it at all intutive what it does and they aren’t very readable.
  • … I think drop-while is pretty easy to read, especially with take-while. And they’re simpler and you can compose them to make something like subsequence-where.

Proposal: accept the PR.

Accepted.

See PR #2948

• CG: I think we can skip this for this week, there’s been nothing new.

See PR #2941

• CG: There’s history here. We added fn:current to XQuery but it’s meaning is a little different from XSLT.
  • … We added it to use as a default parameter, allowing the default to refer to the caller’s context.
• CG: But fn:number and user-defined functions are defined differently.
• CG: This PR changes the definition to do that.

CG reviews the XQuery spec.

• MK: Is the context value available in every module?
• CG: Good question! I’d need to look that up. That would effect what fn:current() does.

After a bit of investigation: it can only be defined in the main module.

• RD: If you have a step expression and a filter expression, that changes the meaning of ..
• CG: Yes.
• CG: The result of the changes it that you can write user-defined functions similarly to system functions.
  • … And we can use := . in the system functions because that will always refer to the caller.
• CG: We’ve unified the meaning of fn:current() and the ..
• JLO: Does this mean that we will allow user functions to have a default value of ..
• CG: Yes. It’s already possible, but it doesn’t mean what you think it means!
• JLO: I remember changing our function implementation to allow . to access the context.
• MK: I think we’re at cross purposes; you can’t use . inside the function, only as the default value of an argument.

Proposal: accept the PR.

Accepted.