QT4 CG Meeting 014 Minutes 2022-12-06

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

Proposal: Accept the agenda.

Accepted.

The next meeting is scheduled for Tuesday, 13 December.

Possible regrets from MK; he will try to make it.

Proposal: Accept the minutes of the previous meeting.

Accepted.

• [ ] QT4CG-002-10: BTW to coordinate some ideas about improving diversity in the group
• [X] QT4CG-013-01: MK to refine the coercion rules with respect to enumeration types
  • https://github.com/qt4cg/qtspecs/issues/283
• [X] QT4CG-013-02: DN to provide a concrete example of the function case discussed with respect to coercion rules.
  • https://github.com/qt4cg/qtspecs/issues/281#issuecomment-1336491005
• [X] QT4CG-013-03: MK to raise a separate issue about sequence/array out-of-bounds handling
  • https://github.com/qt4cg/qtspecs/issues/278

The next few meetings scheduled after this one are:

• [X] 13 December 2022
• [X] 20 December 2022
• [ ] 27 December 2022
• [ ] 3 January 2023

Meetings on 27 December and 3 January are canceled.

Placed before PR #250 because I think it’s relevant to closing that issue.

• MK: I was given an action last week to write up what we should do: see #278.
  • … The primary problem is the asymmetry of array and sequence bounds checking
  • … We discussed how we might address this asymmetry
  • … The most promising is to use the static context

Mike walks us through the prose of the issue.

• MK: I think “do nothing” is the default if we can’t find a good solution.
  • … Adding an option to the static context has the advantage that it applies to both functions and operators.
  • … Reviews a sketch of the consequences for both arrays and sequences
  • … DN points out that array:get would then have the same ambiguity as map:get.
    • … Could be addressed with an array:contains function or by manually checking.
  • … DN proposes returning a magic value, but MK is ill disposed to the idea.

The question is, do we want to pursue this?

• DN: Thank you. But there were some later thing that you didn’t mention. I want to express the opinion that I’m absolutely opposed to allowing array functions to return ambiguous results.
  • … The best constructive example I could find is the try/get value in dictionaries in C# and several other data types.
  • … The solution is simple. Just return a composite result: did the request succeed, and what was the value.
  • … This has been tried in the .NET world for at least a decade and programmers are happy with it (no issues).
  • … We should do this when we want to resolve the ambiguitty with arrays.
• NW: Question of clarification…
• DN: It would be a new function array:try-get().
• MK: A composite function would also be useful for maps.
• BTW: Couldn’t it always be a tuple? Why does it have to be different?
• RD: We can’t really retrofit for existing functions.
• MK: Yes, this would be for a new function and independent of the static context option.
• MSM: If we introduce try-get with a composite result, then does that mean we can just leave out the static context option? What does array:get do if bounds checking is turned off.
• DN: I think array:get will continue to raise an error.

Some discussion of how these new functions and the static context option.

• RD: There are examples using sequences where you can have an expression that returns 0 where you don’t have an item. If we made that throw an exception, then you could cause failures when the static context checking is enabled. Because that code won’t have try/catch around it, it won’t behave as you’d expect it to.
• MK: If we had a function try-get for arrays, maps, and sequences, and perhaps a few other cases (like head), would that be an adequate solution to this problem?
• NW: I was going to ask the same thing, it sure sounds that way to me.
• MSM: It has the advantage that it’s the same programmer accessible action in each case.
• NW: I think not changing the static context is a win.
• JL: The try-get will give you back a tuple that you have to bind into a variable in order to check the value.
• DN: There is the possibility to have a new feature here were you can assign to mulitple variables.
• RD: I have a proposal to do that, #37.

Proposal: add try-get for arrays and maps and call it done?

• JL: Would we add array:contains?
• MK: I worry the name would be missleading.
• MSM: I don’t see how try-get for arrays and maps handles the absence of bounds checking for sequences.
  • … I’m still not completely sold on this at all.
  • … It strikes me as close to the point of a much smaller group, much later revisiting the basic design choices of a previous larger group.

Proposal: add try-get for sequences, arrays, maps and call it done?

• DN: In this proposal, we’re missing a way to say that an unsuccessful search operation on a sequnce should throw an error.
  • … That would give us parity between sequences and arrays.
• BTW: I like the point DN made about having absolute symmetry between arrays and sequences is perhaps only necessary if we’re implying arrays and sequences are the same kinds of things, which they aren’t. They are different, so doesn’t it make sense that they should behave differently?
• DN: I competely agree, the only use case I’ve found for introducing errors when unsuccessfully searching a sequence is because it will surprise Haskell programmers. Perhaps we can ignore it.
• MK: There’s always the trivial example of people writing $x[0] and wondering why that doesn’t raise an error since it’s nonsense.
• RD: I think try-get functions for arrays and maps could be quite useful. If that solves the original problem that DN raised, then I think that should resolve it.

ACTION: QT4CG-014-01: MK to propose new try-get functions for arrays, maps, and (maybe) sequences

See pull request #250 and the minutes of meeting 013.

• DN: I think fn:final() and fn:prefix() are much better than fn:foot() or fn:truncate()
• NW: Is naming the only problem?
• MK: I think there’s also the problem of array:head() on an empty sequence.
• DN: I’d be happy to use try-get
• MSM: Then I suggest what we do is put that as a question.
• DN: The question of having array:head can also be resolved by array:exists() and array:empty().
• MK: That’s a bit similar to the duality of map:contains() and map:get().

Some discussion about the names. They aren’t the best names, but that ship has sailed.

Proposal: Add array:exists() and array:empty() functions?

Accepted.

ACTION: QT4CG-014-02: MK to draft a spec for array:exists() and array:empty() functions

Proposal: With try-get functions and the new array functions, we have sufficient tools to deal with array bounds checking in head

Accepted.

• NW: So we’re down to just the names. What’s the right answer?
• MK: The problem with prefix is that it’s strongly associated with QNames

General agreement that fn:foot() is ok, but fn:truncate() isn’t great.

• BTW: I propose fn:trunk(). It’s a noun and has lots of good connotations.

Proposal: Accept #250 using the names fn:foot and fn:trunk

Accepted.

ACTION: QT4CG-014-03: MK to update PR #250 with the new names

• DN: I suggest we make BTW our linguistic ambassador.

There’s been some discussion of this issue in the comments. I think it might benefit from some face-to-face discussion. I propose to time-box this discussion to say 20 or 30 minutes.

• NW: Suppose I want to use a package for Node or Perl or Python or TeX or C# or…

  1. I run the package manage to download the code
  2. I stick some simple import statement at the top of my code
  3. I use it.

  I think we’d be helping the QT community if we made that possible. Solutions like the one DN outlined in the issue are clever, but I don’t think they’re really sufficient. They’re beyond the reach of ordinary mortals. But maybe I’m wrong. I don’t think it’s a lot of work, but is it worth doing?

• DN: I disagree that my proposal is beyond ordinary mortals.
• RD: I think it has a couple of issues; how do you locate the packages so they can be searched etc. How do you make it so that you can work offline. How do you fit it in with existing mechanisms and existing vendors? How does it work for existing vendors? And how do you make it so you can have a single package that can support all of those.
• DN: I’m using environment variables to specify a list of URLs in which to look for module. Speaking about expressing the functions as leaf nodes of a tree of a map doesn’t mean that they have to be presented that way to the end user. That could be addressed by having “the loader” generate functions in a particular namespace. This also answers one tricky question which is how to use the namespaces. If we want to achieve something similar to the hiearchical namespaces of many programming languages, then using a tree could naturally lead to the namespace URL and to a tree of namespaces. This could lead to natural levels of abstraction. I’m not sure if designing tools for the languages is part of our subject area. We don’t have a formal remit to do this.
• MK: To make this work, there are three ingredients that need to be in place: 1. language syntax; that’s why use-package and so on in XSLT were designed. 2. defining a service and protocols; the specification of machinery for how a repository would interface with the world. 3. engineering and operation of a repository; we’re not that kind of group and I’m not sure how that would work.
• BTW: Building on what MK said, is this then something for which a separate group is needed. Someone with an explicit remit to do the engineering for this?