Intent for large operators

[NSoiffer]

There are about 10 large operators that probably make sense to go into core (maybe integral, double integral, triple integral, contour integral, surface integral, volume integral, sum, product, coproduct, union, intersection). Likely what result is decided for core should be extended to open for the other large operators (e.g., ⊍).

These are all very similar in structure in that intent potentially goes on msub/munder with one argument (typically specifying a domain for the "index") and msubsup/munderover with two arguments ("... from xxx to yyy"). Or they go on some containing mrow with an additional argument (e.g., "... from xxx to yyy of zzz"). If they go on one of the scripting elements, then there is no need for intents for indefinite integration or sums that don't have limits. If they go on an mrow, then maybe it makes sense to have an intent for them although Neil felt the speech needs no intent because there is no other sensible speech for "integral", "sum", etc.

In the Dec 21 meeting, no one stood up for the "dx" being part of the argument for integral as it would be spoken "dx" wherever it was and didn't need help from an intent.

In the meeting, Neil felt that listing these all out both uses up a lot space (and hence appears complicated) and more importantly, obscures their similarity making it harder on both generators and consumers of the spec. His suggestion is to create another list between the "Core Concept Default Fixity properties" and the "Core Concept Templates". Others were not enthusiastic with that idea.

This issue provides a place to discuss the pros and cons of how intents for large operators should be handled.

[dginev]

I'm generally skeptical that custom names offer a significant advantage (e.g. reduced list length) over consistently following a uniform naming convention. Uniform naming keeps the learning curve as small as possible, and aids adoption.

To an adopter, a new large-operator entry raises the question why we don't have prefix-operator, postfix-operator or infix-operator. To me this looks like the same kind of pattern that is addressed by :prefix, :infix, etc properties. I would have imagined those fond of fixity properties would have added yet another fixity construct, as in :indexed-operator or simply :indexed, and documenting the list of (10?) Core large operators to be in that "default fixity".

In the absence of some consistent rule for choosing argument order, we'd need to document each case separately, which is why I had previously raised #478 .

[NSoiffer]

I'm not advocating adding a "large-operator" concept name -- I'm merely advocating for an organizational arrangement of the names that groups the large operators together to avoid a lot of repetition. My goal is to reduce the size and apparent complexity of the spec.

I do think we need to add a few more "fixity" options, but that's not what this thread is about. This thread is about where the intent for large operators should be placed/what the number of arguments are to the intent along with how we should describe them.