QT4 CG Meeting 015 Minutes 2022-12-13

Regrets: BTW, CG, RD, and EP.

• [ ] Anthony (Tony) Bufort (AB)
• [ ] Reece Dunn (RD)
• [X] Sasha Firsov (SF)
• [ ] Christian Grün (CG)
• [X] Joel Kalvesmaki (JK) [0:25-]
• [X] Michael Kay (MK)
• [X] John Lumley (JL)
• [X] Dimitre Novatchev (DN)
• [ ] Ed Porter (EP)
• [ ] Liam Quin (LQ)
• [ ] Adam Retter
• [X] C. M. Sperberg-McQueen (MSM)
• [ ] Bethan Tovey-Walsh (BTW)
• [X] Norm Tovey-Walsh (NW). Scribe. Chair.

Welcome Sasha Firsov. A brief round of introductions.

• SF: I’m trying to be an open source contributor and web developer. Doing architectural work, trying to put some work on W3C in order to make decorated web applications a thing. When multiple applications from different vendors meet on the same page, there are technologies we need. Transformation is an essential part of that. I’m hoping to make a bridge between HTML DOM and XSLT communities.
• NW: Works for Saxonica. Been doing XML since there was XML. I worked on the XProc specification.
• JL: Spent seven years working for Saxonica. Wrote the XSLT versions of the XSLT and XPath 3 compilers in SaxonJS.
• MSM: Got interested in declarative markup in the late 1980s. Worked on XML. Worked for W3C for a decade. Spent time on various working groups.
• MK: I haven’t been in the game as long as NW and MSM, only about 20 years. I’ve beeen developing Saxon all that time and became editor of the XSLT spec on version 2.0.
• DN: I have been active in the XML space for maybe 20 years. Maybe I’m most well known for the FXSL library for XSLT 1.0 then 2.0. Did some presentations at conferences. I represented Microsoft on the XSLT WG, but for the last 10 years I’ve been actively pushing for pure XPath programming. You can see more about me by looking at the proposals I’ve submitted.

Proposal: Accept the agenda.

• NW: We’ll skip the parse-html PR in RD’s absence.
• DN: Two meetings ago, I was tasked with an action item, to clarify the way function arguments are evaluated when a function returns a function. I’d like to talk about issue #281.

Accepted with those amendments.

The next meeting is scheduled for Tuesday, 20 December.

No regrets heard.

Reminder, the CG Will not meet on 27 December or 3 January.

Proposal: Accept the minutes of the previous meeting.

Accepted.

• [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
  • Continued
• [ ] QT4CG-014-01: MK to propose new try-get functions for arrays, maps, and (maybe) sequences
  • Continued
• [X] QT4CG-014-02: MK to draft a spec for array:exists() and array:empty() functions
• [X] QT4CG-014-03: MK to update PR #250 with the new names

• DN: Consider this comment on the issue: if, in $f($x)($y), is it possible for $y to be evaluated before $f($x)? If $f($x) returns a constant function, is it still possible for $y to be evaulated? What do the current rules say?
• MK: I’m reading section 4.4.2.1, evaluating dynamic function calls. Step 1 is to evaluate the base expression, $f($x) to get a function, then we ask if the arity matches the number in the argument list. It doesn’t so we raise a type error. Step 2 says that we evaluate the arguments. I think in a numbered list we assume the items are performed in the order of the list.
• DN: There were new rules for coertion which were proposed. According to those rules, a type error would not be raised.
• MK: There’s no coercion here because we’re not binding the result to a variable or function argument.
• DN: But this is the result of the function, and coercion rules apply there too. So we’re expecting a 1 argument function and we get a 0 argument function. That would be wrapped in a function.
• MK: That would be true if they were applied, but I don’t think they are.
• MSM: You’re (DN) saying that $f($x) is supposed to be a one argument function, then we’ll coerce it to be one. But we can’t know that here, so we won’t coerce it. Do we have a declaration for $f that it is a one argument function that returns a one argument function?
• DN: My understanding is, the way the expression is written, it expects the evaulation of $f to return a one argument function. My understanding is that if it returns a constant function, we shouldn’t throw an arity expression. Maybe we should add a rule that there is no arity exception. This is explicitly writing a partial function evaluation.
• SF: It’s about integrity of the language. There are a few different things. If $f returns another function or “none”, we could make the evaluation of $y conditional on that invocation. Consider JavaScript’s “?.”. Do you want $x and $y both to be evaluated? That’s a question for the programmer. If you do want to evaluate both, you would create a function that will accept arguments $x and $y, then invoke $f inside that. Quite often folks in software development, use the arguments just to assure that it’s evaluated. In JavaScript, you can use a comma separator which means everything will be evaluated.
• DN: If you could add your comment to this thread, that might be easier to understand. I just wanted to pose the question, I think the right answer is that $y shouldn’t be evaluated until the result of $f is returned.
• NW: I thought Mike’s prose was clear about the order, but it’s unclear about the arity.
• MSM: Do we do lists in order?
• MK: It’s certainly true that if the first raises an error, you don’t do the second.
• MSM: Unless otherwise specified, shouldn’t an implementation be allowed to evaluate $y greedily?
• MK: We don’t have that level of formality in the specifications.
• DN: I think this particular example should be in the specification.
• NW: Let’s take this up again next week. Several folks who commented on the thread aren’t here today.
• JL: I’ve been looking at 4.4.4, the function coercion rules, is DN suggesting that the type of the left hand thing is determined by the existence of the argument. Because it has a single arity, he’s implying that the function coercion rules apply, and I can’t see that.
• DN: I’ve asked several times, if the coercion rules apply only to the function or to the return value. I’ve been consistently told that it applies to the return.
• MK: But they only apply where there’s a declared required type. In this case, there’s an implicit requirement (like a + operator implicitly requires a number), but there isn’t an explicit type.
• DN: Then my proposal is to think about changing the rules, because I think this is only logical. Why should we make any kind of exclusion from the rules here?
• MK: It’s a tenable situation, we could apply that rule here.
• MSM: If we declare $f as an arity one function that returns an arity one function, then presumably the coercion rules do apply.
• DN: This seems like casting in C#.

Some further discussion of how the new corecion rules apply before breaking off until next week.

See pull request #258

Mike leads us through the change.

• MK: There was a comment that $input should be named $array.

ACTION QT4CG-015-01: MK to change the name of the argument to array:index-where from $input to $array

Proposal: accept this PR with the name change.

Accepted.

See pull request #259

Skipped this week.

See pull request #261

Skipped this week.

See pull request #268

Norm introduces the diagrams.

• MK: It would be nice if they were scaled to fit.
• NW: Yes, but then they’d illegible.
• SF: There are other techniques that could be used to make them fit.
• NW: Yes, but these are generated, so manual positioning isn’t a practical option.
• DN: How about rotating the wide one 90 degrees?
• NW: Maybe. But only if we rotate the text too, otherwise the first row is too wide.
• MSM: Two suggestions and a question. For the first figure, make the lgend verical. The secondl ooks promising to me, I think you might be able to get what you need by specifying three ranks. My question is, what is the meaning of the directional arrow? I wonder if people will find it more intiutive if the arrow meant is-the-parent-of/basetype-of and went the other way.
• NW: I did it that way because thaty’s the way they were in 3.1.

Some discussion of UML conventions.

• MSM: I think arrows going the other way would be a little more intuitive, but the meaning of the directional arrow should be in the legend.
• MK: UML does them that way, whether you like it or not
• MSM: Okay.
• JK: Maybe just do an XML tree for the really wide diagram?

Proposal: these diagrams are an improvement, accept this PR

Accepted

ACTION QT4CG-015-02: NW to improve the width of the diagrams, perhaps multiple views ACTION QT4CG-015-03: NW to make sure the direction of the arrow is in the legend

• DN: There are a number of JavaScript controls that provide expanding and collapsing.

ACTION QT4CG-015-04: NW to investigate of a dynamic presentation is practical

See pull request #279

• MK: This is just an attempt to clarify the presentation; there aren’t any tehcnical changes.
  • … We’ve taken a section that bundled together three things about overriding and made them separate.
  • … There are rules about package import precedence, extension functions, and then override in a used package.

Proosal: Accept this PR.

Accepted.

See pull request #284

Skipped this week.

MK proposes that this issue may be ready to be decided.

• MK: Does anyone remember why we postponed this issue? There’s no explicit action waiting to be done.

No, we don’t. NW to make sure it’s higher on the agenda next week.

MK proposes that this issue may be ready to be decided

Resolved by the earlier PR.

MK proposes that this issue may be ready to be decided.

• MK: Is this worth doing? I don’t want to spend the time on the PR unless there’s general agreement that it’s a good idea.
• MSM: How much violence does this do to the grammar?
• MK: Not much, it just allows a union.
• MSM: As long as we can be sure it isn’t ambiguious.

ACTION QT4CG-015-05: MK to raise a PR to resolve issue #107, self::(a|b|c)