QT4 CG meeting 014 draft minutes, 6 December 2022

See

  https://qt4cg.org/meeting/minutes/2022/12-06.html

QT4 CG Meeting 014 Minutes 2022-12-06

Table of Contents

     * [1]Draft Minutes
     * [2]Summary of new and continuing actions [0/4]
     * [3]1. Administrivia
          + [4]1.1. Roll call [8/13]
          + [5]1.2. Accept the agenda
          + [6]1.3. Next meeting
          + [7]1.4. Approve minutes of the previous meeting
          + [8]1.5. Review of open action items [3/4]
          + [9]1.6. Schedule for upcoming meetings
     * [10]2. Technical Agenda
          + [11]2.1. Issue 278, array bounds checking
          + [12]2.2. Review pull request #250: fn:foot, etc.
          + [13]2.3. Issue 274, building a module repository for QT
     * [14]3. Any other business
     * [15]4. Adjourned

Draft Minutes

Summary of new and continuing actions [0/4]

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

1. Administrivia

1.1. Roll call [8/13]

     * [ ] 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.

1.2. Accept the agenda

   Proposal: Accept [16]the agenda.

   Accepted.

1.3. Next meeting

   The next meeting [17]is scheduled for Tuesday, 13 December.

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

1.4. Approve minutes of the previous meeting

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

   Accepted.

1.5. Review of open action items [3/4]

     * [ ] 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
          + [19]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.
          + [20]https://github.com/qt4cg/qtspecs/issues/281#issuecomment-1
            336491005
     * [X] QT4CG-013-03: MK to raise a separate issue about sequence/array
       out-of-bounds handling
          + [21]https://github.com/qt4cg/qtspecs/issues/278

1.6. Schedule for upcoming meetings

   The next few meetings scheduled after this one are:
     * [X] 13 December 2022
     * [X] 20 December 2022
     * [ ] [DEL: 27 December 2022 :DEL]
     * [ ] [DEL: 3 January 2023 :DEL]

   Meetings on 27 December and 3 January are canceled.

2. Technical Agenda

2.1. Issue 278, array bounds checking

   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 [22]#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.
               o ... 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, [23]#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

2.2. Review pull request #250: fn:foot, etc.

   See [24]pull request #250 and the [25]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.

2.3. Issue 274, building a module repository for QT

   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?

3. Any other business

   None heard.

4. Adjourned

References

   1. https://qt4cg.org/meeting/minutes/2022/12-06.html#minutes
   2. https://qt4cg.org/meeting/minutes/2022/12-06.html#new-actions
   3. https://qt4cg.org/meeting/minutes/2022/12-06.html#administrivia
   4. https://qt4cg.org/meeting/minutes/2022/12-06.html#roll-call
   5. https://qt4cg.org/meeting/minutes/2022/12-06.html#agenda
   6. https://qt4cg.org/meeting/minutes/2022/12-06.html#next-meeting
   7. https://qt4cg.org/meeting/minutes/2022/12-06.html#approve-minutes
   8. https://qt4cg.org/meeting/minutes/2022/12-06.html#open-actions
   9. https://qt4cg.org/meeting/minutes/2022/12-06.html#upcoming-meetings
  10. https://qt4cg.org/meeting/minutes/2022/12-06.html#technical-agenda
  11. https://qt4cg.org/meeting/minutes/2022/12-06.html#iss-278
  12. https://qt4cg.org/meeting/minutes/2022/12-06.html#pr-fn-foot
  13. https://qt4cg.org/meeting/minutes/2022/12-06.html#iss-274
  14. https://qt4cg.org/meeting/minutes/2022/12-06.html#any-other-business
  15. https://qt4cg.org/meeting/minutes/2022/12-06.html#h-C42F89DC-52DF-40F2-B5BA-288B982BE9DA
  16. https://qt4cg.org/meeting/agenda/2022/12-06.html
  17. https://qt4cg.org/meeting/agenda/2022/12-13.html
  18. https://qt4cg.org/meeting/minutes/2022/11-29.html
  19. https://github.com/qt4cg/qtspecs/issues/283
  20. https://github.com/qt4cg/qtspecs/issues/281#issuecomment-1336491005
  21. https://github.com/qt4cg/qtspecs/issues/278
  22. https://github.com/qt4cg/qtspecs/issues/278
  23. https://github.com/qt4cg/qtspecs/issues/37
  24. https://qt4cg.org/dashboard/#pr-250
  25. https://qt4cg.org/meeting/minutes/2022/11-29.html#pr-fn-foot

                                        Be seeing you,
                                          norm

--
Norm Tovey-Walsh
Saxonica

Received on Tuesday, 6 December 2022 17:22:26 UTC