- From: Norm Tovey-Walsh <norm@saxonica.com>
- Date: Tue, 27 Sep 2022 17:40:49 +0100
- To: public-xslt-40@w3.org
- Message-ID: <m2y1u4db1v.fsf@saxonica.com>
See https://qt4cg.org/meeting/minutes/2022/09-27.html
For your convenience, here’s a text copy of the minutes.
QT4 CG Meeting 004 Minutes 2022-09-27
Table of Contents
* Draft Minutes
* Summary of new and continuing actions [0/7]
* 1. Administrivia
* 1.1. Roll call [9/12]
* 1.2. Accept the agenda
* 1.3. Next meeting
* 1.4. Approve minutes of the previous meeting
* 1.5. Review of option action items [4/6]
* 2. Technical Agenda
* 2.1. Approve proposed changes to fn:all and fn:some
* 2.2. Approve changes in changes-agreed-2022-09-20 branch
* 2.3. XPath 4.0 functions
* 2.3.1. Variadic functions
* 2.3.2. Move fn:deep-equal higher up the list?
* Returning to the list of functions…
* 2.3.3. fn:intersperse
* 3. Any other business
Draft Minutes
Summary of new and continuing actions [0/7]
* [ ] QT4CG-002-01: NW to incorporate email feedback and produce new
versions of the process documents.
* [ ] QT4CG-003-03: NW to tweak the CSS for function signatures to avoid
line breaks on - characters.
* [ ] QT4CG-002-10: BTW to coordinate some ideas about improving
diversity in the group
* [ ] QT4CG-004-01: MK (with DN and RD) to draft a new proposal for
variadic functions
* [ ] QT4CG-004-02: DN to make a proposal for deep-equal-safe for future
discussion
* [ ] QT4CG-004-03: MK to draft a pull request implementing
fn:intersperse
* [ ] QT4CG-004-04: DN to open an issue for the inverse of
fn:intersperse
1. Administrivia
1.1. Roll call [9/12]
Regrets: Bethan Tovey-Walsh
* [ ] Anthony Bufort (AB)
* [X] Reece Dunn (RD)
* [X] Christian Grün (CG)
* [X] Joel Kalvesmaki (JK)
* [X] Michael Kay (MK)
* [X] John Lumley (JL)
* [X] Dimitre Novatchev (DN)
* [X] Ed Porter (EP) [0:08-]
* [ ] Liam Quin (LQ)
* [X] C. M. Sperberg-McQueen (CSM)
* [ ] Bethan Tovey-Walsh (BTW)
* [X] Norm Tovey-Walsh (NW). Chair. Scribe.
1.2. Accept the agenda
Proposal: Accept the agenda without amendments.
No objections.
1.3. Next meeting
The next meeting is scheduled for Tuesday, 4 October. Any regrets?
Regrets: JL
1.4. Approve minutes of the previous meeting
Proposal: Accept the minutes of the previous meeting as amended on
20 September 2022 by MK.
No objections.
1.5. Review of option action items [4/6]
(Items marked [X] are believed to have been closed via email before this
agenda was posted.)
* [ ] QT4CG-002-01: NW to incorporate email feedback and produce new
versions of the process documents.
* [X] QT4CG-003-01: MK to find a way to specify fn:characters() more
formally
* https://lists.w3.org/Archives/Public/public-xslt-40/2022Sep/0044.html
* [X] QT4CG-003-02: MK to propose a reformulation of fn:index-of() in
terms of fn:index-where()
* https://lists.w3.org/Archives/Public/public-xslt-40/2022Sep/0045.html
* [ ] QT4CG-003-03: NW to tweak the CSS for function signatures to avoid
line breaks on - characters.
* [X] QT4CG-003-04: MK to rename fn:uniform() and fn:unique() to
fn:all-equal() and fn:all-different(), respectively
* https://github.com/qt4cg/qtspecs/commit/f4b331869f0d75a5a706c01cc0655625fe065fa0
(see below)
* [X] QT4CG-003-05: MK to consider how fn:array-filter() could be
generalized to handle array predicates on the index as well as the
value.
* https://lists.w3.org/Archives/Public/public-xslt-40/2022Sep/0046.html
* CSM: I think BTW had an action related to diversity that’s been lost.
* NW: Indeed, I’m not sure I recorded that as an action. My apologies.
I’ll add it to the list.
2. Technical Agenda
2.1. Approve proposed changes to fn:all and fn:some
Mike completed his action. I’ve republished the PR so that it builds
against the updated infrastructure.
Approved.
2.2. Approve changes in changes-agreed-2022-09-20 branch
Mike created a branch which renames fn:uniform() and fn:unique() per his
action QT4CG-003-04 and adds a few other editorial improvements.
Approved.
2.3. XPath 4.0 functions
2.3.1. Variadic functions
Dimitre proposes that we should discuss variadic functions sooner rather
than later:
“WRT our dependency sorting, can we discuss with high priority and
approve the XPath 4.0 variadic functions, so that immediately after that
we could typically describe not N overloads of a proposed function, but
just a single signature containing keyword arguments with defaults?”
* CSM: I think we should talk about it, but I doubt we’re ready to make
a decision. Mostly, at the moment, I want to raise a deeper question:
are we sure we want to do this? I’m nervous because there was a time
when the QT WGs had multiple people who spent their careers doing type
theory, and we didn’t do it then. Are we sure we have the necessary
experience to avoid the pitfalls?
* RD: I do have a working implementation of the variadic function calls,
mapping function arguments to function parameters. That’s implementing
the current spec plus one the issues that I raised around that…#
(separating the variadic type from …)
* MK: I think caution is absolutely justified. It occurred to me this
morning, trying to do my revised way of presenting the design, that
one thing that’s badly lacking so far is the substitutability rules.
Let’s go back to why we’re trying to do this?
* The primary aim is to make the functions we already have more
extensible. Doing it by always adding more isn’t always what you
want.
* The “options map” option was introduced in 3.1 and a lot of folks
think that could be more useful with keyword parameters.
* There are good motivations for wanting to do it, but I share
CSM’s concern about the potential complexity. We fell into type
theory traps in 3.1 and we have bugs in the spec.
* JL: Do you have an example?
* MK: Yes, I forget exactly where it is, but we talk about the type of a
map when considered as a function and we talk about having the “least
common type” of two types, and that phrase is used glibly without
realizing that our type system doesn’t have that concept.
* JL: The hardest thing I recall in the later stages of SaxonJS was
substituting functions. Everything gets turned upside down and adding
variadic seems really tricky.
* RD: In terms of named keywords, one of the cases where that is useful
is if you have three or four boolean parameters. Having names allows
you to know exactly which things are “true”, “true”, and “false” for
example. Constructing a map and passing it into a function call can be
complicated where passing them on the function would be easy.
* CSM: Sanity check, I think based on my reading of the proposal, that
if I have three parameters all of them declared single, booleans. I
can use their parameter names as keywords: a=true, b=true, c=false, in
whatever order is rhetorically best at the point of call. I haven’t
quite got my head around optionality and keyword parameters.
* MK: I think optional parameters are relatively low risk. It’s the
truely variadic ones that create potential complexity.
* RD: That’s the ones that bind a sequence to a set of parameters…
* MK: Yes.
* DM: I think this proposal stemmed from a conversation that I had with
Mike in chat. I was thinking only keyword parameters, which seem low
risk. We should focus on the challenging things.
* The benefits of having this as early as possible in our process
is very large. This can lead to significant simplification of the
documents. We can avoid the need to have many different function
signatures.
* RD: I wonder if it makes sense to divide this up a bit, rather than
tackling all at once.
* The initial goal that DN brought this up for was specifying
default parameters on functions to reduce the complexity in the
F&O spec. That would require bounded variadic functions which
keep the functionality between an upper- and lower-bound with
specified defaults.
* And we could allow keyword arguments.
* I don’t think that adds anything to the type system. At some point in
the future, we can look at how to apply these to sequence types and
map types.
* NW: If we can decompose the problem into smaller pieces, that’s a good
thing.
* MK: That sounds like a good idea to me.
* RD: We can always add things in the future.
* MK: One question, particularly of Dimitre. Do we want keyword
parameters on dynamic function calls?
* DN: I think that’s an extremely good question. It only matters if we
define a dynamic function and then we have a large scope where we use
that function. If there are a lot of calls to that function, then it
would be helpful to users. I’m not ready to say “yes” very firmly, but
I do see use cases where it can be useful.
* MK: I think its a lot more difficult to define things like partial
function application if we need to do it in the dynamic case.
(Some discussion of “boundedness” and “unboundedness in Zoom chat.)
* CSM: Keyword parameters do help deal with functions with lots of
parameters – but I worry that it's just attempting to evade Perlis's
maxim that "if you have a function with ten parameters, you probably
missed one"
* CSM: Q. I am not finding the words "bounded" and "unbounded" in MK's
proposal. Meaning?
* CG: I assume that fn:concat is an example for a function with an
unbounded number of maximum arguments. Some more details are given in
the current version of the draft:
* MK: The terms appear not in my email of this morning, but in the
original proposal. In this morning’s proposal, I attributed a
plurality to each of the arguments. A bounded variadic function is
basically one that has single and optional arguments, but doesn’t have
multiples or maps.
* JL: Is concat the only function we have with multiple, unbounded
arguments?
* RD: That’s the only one in the spec, but other implementors have tried
to generalize the idea in other functions. BaseX out-format is
variadic, so is allow, and the XQuery rest-consumes, etc… Various
MarkLogic functions are also variadic.
* MK: In this area, it’s an awful lot easier to do something in an
implementation than it is in a specification.
* NW: Does it make sense to come back with new drafts for just the parts
* JK: Much of the proposal is written from the perspective parsing and
understanding a function. It would be nice to have some discussion of
whether or not function authors are going to have to think about
things differently.
* MK: In a lot of existing function libraries, there’s some possibility
that users will discover that they wish they’d chosen better names.
Those are now going to be public where they’d previously been private.
* RD: The way the draft is currently specified, function authors won’t
have to change the order of things to make things variadic.
Variadicness applies to the last argument. If the last parameter is a
map, you can use the map keys. If the last parameter is a sequence,
you can zero or one or more arguemnts.
* CSM: I think we now have two examples of the utility of what JK
suggests. Correct me if I’m wrong, you’re not limited to a single map
or multiple parameters. That’s the idiom I’m familiar with, but in the
proposal before us, the only constraint is that if I have more than
multiple/map; if I want to reach any of them except the first
declared, I have to use keyword. But if I use keywords, I can have an
arbitrary number of them.
* MK: No, that’s not quite the proposal. In the language of this
mornings proposal, you can have zero or one multiple parameters and
zero or one mapped parameters. You can have zero or more single or
optional parameters.
* CSM: Thank you. I just misread the paragraph.
* RD: I’m basing my comments on the proposal that’s actually in the
current spec; I’ve only read MK’s proposal briefly. It would be good
to have a more formal proposal.
* DN: I’ve missed this morning’s proposal, but can I propose that at
first we concentrate on adding variadic bounded functions. I think
that’s an easier case.
ACTION QT4CG-004-01: MK (with DN and RD) to draft a new proposal for
variadic functions
2.3.2. Move fn:deep-equal higher up the list?
Dimitre observes “some of the functions to be discussed that are included
in the current list/checklist, depend on using a compare() function /
strategy. This makes all of them dependent on having first discussed and
approved fn:deep-equal(options). Therefore, could we move
fn:deep-equal(options) considerably higher in the list, so that it
precedes all such functions that are dependent on a compare()
function/strategy?”
* DN: There are a number of functions higher in the list that can take
different kinds of comparisons (sequence starts with, contains, etc.)
They can use different comparison functions. While we can generally
say that people can specify any comparison function they want, MK and
I discussed a lot about what could be a good comparison function.
* It seems like some options on fn:deep-equal could be a good way
to go to reach consensus on such a function.
* MK: I have no objection to working on deep-equal sooner, but we don’t
have a proposal to discuss at the moment.
* DN: This is related to allowing any items as keys of maps. I
constructed deep-equal-safe in the comments to this proposal. That
could possibly be regarded as a starting point.
ACTION QT4CG-004-02: DN to make a proposal for deep-equal-safe for future
discussion
Returning to the list of functions…
* MK: I’d like to look at the order of the functions on the agenda; some
have fairly well formulated proposals, we should start with those.
MK proposes starting with fn:intersperse.
No objections.
2.3.3. fn:intersperse
* See https://github.com/qt4cg/qtspecs/issues/2
* MK: I think it would be useful to show a sample implementation for a
bit more rigorous definition. There are a couple in the comment.
* CSM: I’m not sure I understand the function. We have examples of how
to call it, but I don’t see an explicit statement of what gets return.
The analogy with string-join makes me nervous.
* DN: The separator can be any sequence, not just an item.
* DN: I have a question about the name, intersperse carries connotations
of randomness.
* MK: If it’s in other languages, that’s good enough.
* CG: It’s in Haskell and Dart.
* DN: What about the reverse? Splitting on a sequence?
* RD: It’s more like “take ‘n’ drop ‘k’ repeat.”
* CSM: I like, in general, the idea of having an inverse if you can
specify it.
Chair interrupts the discussion of the inverse function to get clarity on
the proposal.
Proposal: Accept fn:intersperse
No objections.
ACTION QT4CG-004-03: MK to draft a pull request implementing
fn:intersperse
* RD: I think it’s straightfoward to implement the inverse because
you’re applying a collect to collect one plus the number of
interspersed items.
* NW: That’s more clever than I am…
* CSM: You have to check that the ones you’re removing match the thing
that was inserted.
* RD: It would have to be that you can’t do anything between intersperse
and the inverse, otherwise you’re going to tie yourself into knots.
* NW: It seems more like a “split on matching subsequences” function to
me, and how does the result get returned anyway, given that we don’t
have sequences of sequences?
* DN: It could return it in an array and we probably need an analogous
function to intersperse arrays.
* JK: I think the inverse function might get really complicated with
exceptions and error handling. The analogy to string-join is helpful
here, the inverse would be like tokenize.
* CG: I was wondering if we have a practical use case for such a
function, there’s nothing like this in Haskell and Dart.
* DN: Consider the case where a function takes a single string and the
first thing the function does is tokenize that string. Similar use
cases probably exist for this function.
* RD: Would CSV parsing be a use ase? Tokenize on newlines and…
With time running short, the chair proposes that DN take an action.
ACTION QT4CG-004-04: DN to open an issue for the inverse of fn:intersperse
3. Any other business
None heard.
Be seeing you,
norm
--
Norm Tovey-Walsh
Saxonica
Received on Tuesday, 27 September 2022 16:42:07 UTC