AW: On function names and such like

Thanks for the summary, Norm, with which I completely agree.

My ambitions for bringing this up were rather modest: I noticed some (as I believe) obvious inconsistencies in the existing (!) naming scheme, and I wanted to discuss them before it’s too late. I would be satisfied if we could spend some (definitely limited) time on the entries of my summary, ideally already in the next meeting, and at least approve or reject the status quo:

https://github.com/qt4cg/qtspecs/issues/843

I would be happy to lead through the summary, and I would hope that we can move the entries of “to be discussed” to “settled” – by simple majority vote – so that we can assure users that these functions are (most, most likely) about to stay. That’s it (hopefully ;·)

This being said, and in principle, I would also be ready to discuss a broad alternative for a clean 4.0 solution, with unified names for sequences, maps, arrays, and possibly other future data structures, and possibly in a new namespace. I just don’t see anyone in the group willing to take this on, as it will certainly take a lot of time and effort (if I’m wrong, please raise your hands). If we do it as a joint effort, I fear we won’t do anything else for the next months, without no prospect of success.

Thanks everyone,
Christian
_______________________________________

Von: Norm Tovey-Walsh
Gesendet: Mittwoch, 13. Dezember 2023 11:21
Bis: public-xslt-40@w3.org
Betreff: On function names and such like


Hello all,

After a couple of weeks of discussion[1][2] about naming things, there
seem to be a some quite different perspectives on the problem.

As background, let’s remember that we have a language (or a set of
languages) that evolved over time. We couldn’t anticipate in version
1.0 what we would have in 4.0. We added new features in 2.0 and 3.0
that weren’t anticipated in previous versions either.

We live with decisions (some the result of long and hard battles
within the working group(s)) like the fact that sequences don’t nest
so all individual items are also sequences of length one.

The context for each addition to the language has been roughly: how
can we add new, useful features with a minimum of backwards
incompatibility.

It’s a natural consequence of this sort of evolution that there are
rough edges. Why does fn:count returns the number of items in a
sequence but always returns 1 if the argument is an array? Because an
array is an item and an item is a sequence of length one.

(It doesn’t help that the vision of what the X* languages should be
has changed over time. What started out envisioned as a tool for
transforming documents from one format to another for presentation on
the web or in print has grown into something that at least some
members of the group view as first class, functional programming
languages. That’s not bad, but it puts entirely different stresses on
the design, I think.)

As we add new functions (specifically, in the case of recent
discussions, but I expect the same perspectives apply more generally),
I think one perspective is roughly this:

  How can we name and organize the functions so that users are least
  likely to be surprised and most likely to be able to figure out how
  to solve a particular problem?

Taken to an extreme, this perspective isn’t about changing the
semantics of the functions at all, it’s “just” about naming them. Is
fn:get() better (easier to understand, less confusing) than
fn:items-at?

I think another perspective is roughly this:

  We have a messy design. It would be better if we could refactor the
  design so that it was more harmonious and logical. We don’t need
  four different, closely related functions to get items out of
  different sorts of data structures, we need a set of abstractions
  that make it obvious that only one function is necessary.

Taken to an extreme, this perspective is about reshaping the whole
language so that a single, obvious set of function names emerges
naturally from the carefully constructed abstractions.

I don’t think anyone holds exactly one perspective (discussions about
renaming often involve some level of discussion about semantics, for
example) and I’m attempting to polarize the perspectives a little bit
in an effort to shine light on a larger problem, not to be divisive.

With my chair’s hat on, the main problem I see with the first
perspective is that naming is hard, often personal and emotional, and
will never be wholly logical (so there will always be more to discuss,
so the “problem” is never resolved). It’s not quite fair to say it’s a
distraction from the “bigger” issues we need to resolve, but it does
take a lot of time.

I see the appeal of the second perspective. If we had a green field,
we’d do things differently. I think we might all agree that, ideally,
fn:count should return the number of items in a sequence, the number
of items in an array, and the number of key-value pairs in a map. But
it doesn’t and it can’t without fundamentally breaking things. I don’t
think we’d get agreement to break fn:count, so what can we do?

A proposal to fundamentally redesign the data model would be a tough
sell, I think.

One thing we could do is define a new namespace “gn” with functions
that work more logically, that treat sequences, arrays, and maps, as
collections and operate on them uniformly. 

I suppose we could reconstruct the whole set of functions in this new
namespace and focus our efforts there, perhaps going so far as to
deprecate the current fn: namespace in favor of this new one.
But could we get consensus to do that? Would users thank us?

I dunno. Innovations welcome.

                                        Be seeing you,
                                          norm

[1] https://qt4cg.org/meeting/minutes/2023/12-05.html#h-E01573AE-CAC0-43ED-94F6-05094B3AB8A1
[2] https://qt4cg.org/meeting/minutes/2023/12-12.html#h-DC545309-6A5B-4A3C-AE70-132ABC98B442

--
Norm Tovey-Walsh
Saxonica

Received on Wednesday, 13 December 2023 12:50:07 UTC