Implement shorter modifier name for slanted equal and equiv

[Enivex]

This implements the changes described in #42. Also

• Add additional related variants that should be uncontroversial based on existing choices. There are some more in the document ™, but they require more discussion.
• Naturally introduce the corresponding sequiv.
• This should unblock Precedes and succeeds under relation (Proposal 10) #36, since curly is now freed up

While there a few concerns that have been voiced, I've also not seen any viable alternative for resolving ambiguity. Even seq is not enough to resolve ambiguity for some of the more cursed symbols (⪓).

[MDLC01]

I don't love the seq and sequiv names, but I agree we don't have anything better.

However, I strongly dislike having seq and sequiv as separate symbols, because seq and sequiv don't make sense by themselves.

Maybe a solution would be to replace .slant with .alt. It's not very descriptive, but it may be the right solution. After all, slanted variants are mostly alternate glyphs of non-slanted variants, just like epsilon.alt and phi.alt are alternate glyphs for epsilon and phi.

[Enivex]

I don't love the seq and sequiv names, but I agree we don't have anything better.

However, I strongly dislike having seq and sequiv as separate symbols, because seq and sequiv don't make sense by themselves.

I don't see this as an issue at all. It just makes them usable in the same way the eq variants are. There are plenty of examples of symbols where there is no inherently canonical top variant.

We can be super principled, but ultimately this is a tool we want people to actually use.

It only makes sense to have seq.lt and seq.gt as counterpoints to lt.seq and gt.seq.

Maybe a solution would be to replace .slant with .alt. It's not very descriptive, but it may be the right solution. After all, slanted variants are mostly alternate glyphs of non-slanted variants, just like epsilon.alt and phi.alt are alternate glyphs for epsilon and phi.

This has the same issues as slanted, but even more so. What does the alt refer to?

[MDLC01]

There are plenty of examples of symbols where there is no inherently canonical top variant.

My problem is not that there is no canonical top variant. It is that seq is inherently a modifier. It's like neq is not a symbol by itself (although neq would have a clear meaning by itself).

This has the same issues as slanted

IIRC, the main issue with .slanted was that it was too long to type. .alt is shorter.

[Enivex]

My problem is not that there is no canonical top variant. It is that seq is inherently a modifier. It's like neq is not a symbol by itself (although neq would have a clear meaning by itself).

And I don't see this as an issue at all. Discoverability would almost certainly be through (say) gt., and then it would only be natural to be able to use seq.gt.

We can strive towards the goal of having top level names make sense on their own as far as possible, but I strongly feel that this shouldn't trump usability.

This has the same issues as slanted

IIRC, the main issue with .slanted was that it was too long to type. .alt is shorter.

That's one issue, so alt has that going for it. But

1. It's not inherently clear what part of the symbol is slanted / alternate (there are at least fewer things that can be slanted)
2. You lose the symmetry described above
3. It's less usable than the non-slanted variants (this is important for those that prefer them)
4. Naming some of the missing variants becomes even harder. For instance, ⪨ has no non-slanted version
5. There is already precedence for resolving ambiguity this way with neq

[MDLC01]

1. .alt provides an alternate version of the whole symbol. In this case, this corresponds to a slanted equal/equiv part.
2. I'm not sure what you mean here. With .alt, we would have gt.eq and gt.eq.alt, and eq.gt and eq.gt.alt.
3. Fair.
4. Does this mean ⪨ would be whatever.seq instead of whatever.eq? With my .alt proposal, it would simply be whatever.eq as there is no alternative variant here (unless there is with variation selectors, in which case we should add both).
5. Except, e.g., lt.neq is not an alternate of lt.eq, it's a different symbol with a different meaning. On the contrary, the .alt modifier does not change the meaning of the symbol, but uses an alternate representation of the symbol.

Additionally, regarding discoverability, seq as a symbol means ⪕ would not be listed as a variant of eq in the doc. This can be especially problematic for, e.g., ⪗, which does not have a non-seq version (again, unless Unicode defines variations but that's besides the point).

[Enivex]

1. .alt provides an alternate version of the whole symbol. In this case, this corresponds to a slanted equal/equiv part.

But how does the user know what's going to change?

4. Does this mean ⪨ would be `whatever.seq` instead of `whatever.eq`? With my `.alt` proposal, it would simply be `whatever.eq` as there is no alternative variant here (unless there is with variation selectors, in which case we should add both).

Yes. Using whatever.eq would be both inconsistent and possibly lead to breaking changes down the line if a straight equality version is added. (It has happened several times before that "missing" symbol variants have been filled in)

5. Except, e.g., `lt.neq` is not an alternate of `lt.eq`, it's a different symbol with a different meaning. On the contrary, the `.alt` modifier does not change the meaning of the symbol, but uses an alternate representation of the symbol.

The slanted equal can also have a different meaning, such as inequality modulo a multiplicative constant. It depends on the author.

[MDLC01]

But how does the user know what's going to change?

This is a fair point, but I don't think it is a huge problem: they can just try. Same thing with epsilon.alt which could be epsilon.lunate The modifier does not say "this is what changes", but it provides a common variant of the symbol. I think this is fine, not every detail needs to be encoded in the identifier.

Yes. Using whatever.eq would be both inconsistent

I don't think so. In my mind, .eq roughly means "or equal to", not "or equal to but horizontal".

and possibly lead to breaking changes down the line if a straight equality version is added. (It has happened several times before that "missing" symbol variants have been filled in)

This is a fair point. However, I think Unicode could break many names if they decided to add the right characters. We can't think just in terms of what could be there.

The slanted equal can also have a different meaning, such as inequality modulo a multiplicative constant. It depends on the author.

I did not know that. Do you have examples of documents that use both symbols with different meanings?

[Enivex]

This is a fair point, but I don't think it is a huge problem: they can just try. Same thing with epsilon.alt which could be epsilon.lunate The modifier does not say "this is what changes", but it provides a common variant of the symbol. I think this is fine, not every detail needs to be encoded in the identifier.

• The alternate greek symbol variants are established and well known (though a couple are reversed in typst)
• With the exception of note.quarter.alt, note.eighth.alt (which I'm not a fan of either) and epsilon.alt.rev (and only because we reversed epsilon naming), every single use of .alt is as a single modifier, not as an alternate version of a symbol with a bunch of other modifiers.
• Someone writing gt.alt or eq.alt will be very confused.

Yes. Using whatever.eq would be both inconsistent

I don't think so. In my mind, .eq roughly means "or equal to", not "or equal to but horizontal".

In my mind it means the latter, because that's how it's consistently used across the board. With the exception of the symbols we're trying to fix now.

and possibly lead to breaking changes down the line if a straight equality version is added. (It has happened several times before that "missing" symbol variants have been filled in)

This is a fair point. However, I think Unicode could break many names if they decided to add the right characters. We can't think just in terms of what could be there.

No, but we don't have to make the job harder for ourselves for no reason either.

The slanted equal can also have a different meaning, such as inequality modulo a multiplicative constant. It depends on the author.

I did not know that. Do you have examples of documents that use both symbols with different meanings?

I don't have any explicit examples no, but I've seen both ≲ ≺ and ⩽ used for this purpose, with the first one being by far the most common.

[MDLC01]

The alternate greek symbol variants are established and well known (though a couple are reversed in typst)

I think the same could be said of the two variants of the less than or equal signs.

every single use of .alt is as a single modifier, not as an alternate version of a symbol with a bunch of other modifiers.

I don't see why we would want to keep that as an invariant of symbol naming.

Someone writing gt.alt or eq.alt will be very confused.

This is a fair point, but also a more general problem with our current system. #51 aims to solve that, but before this or a different solution is implemented, I agree this would be a bit awkward (although not much more than any other similar situation that already exists).

In my mind it means the latter

Fair.

No, but we don't have to make the job harder for ourselves for no reason either.

Fair.

I don't have any explicit examples no, but I've seen both ≲ ≺ and ⩽ used for this purpose, with the first one being by far the most common.

Without actual examples of ⩽ and ≤ being used with different meanings, I can't help but think of both as alternate glyphs of each other.