- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 06 Dec 2022 17:21:01 +0000
- To: public-xslt-40@w3.org
- Message-ID: <m2pmcwbg73.fsf@saxonica.com>
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