Semantic Tokens: Distinguish (possibly-partially-applied) infix operators from normal functions/variables

[konn]

Is your enhancement request related to a problem? Please describe.

First of all, thank you @soulomoon for implementating fantastic support for semantic tokens! I've long been waiting for this feature 🎉

After the release of 2.6.0.0, I've just tested it and looks really good. I think it will become even better if one can tell (possibly partially-applied) infix operators from ordinary variable/functions semantically.

For example, the image below is what I apply One Monokai + Semantic Tokens to the code fragments containing several ($)s:

In above, functions being applied and ($)s are all coloured homogeneously. Without semantic colouring, OTOH, we got:

I think the latter case gives more legible highlighting - binary operator shines between functions.

Describe the solution you'd like

Add something like TBinaryOperator constructor to HsSemanticTokenType, map its default to operator token, and also allowing users to map them to what they like (as we already did for haskell.plugin.semanticTokens.config.dataConstructorToken etc).

Describe alternatives you've considered

Perhaps, as we have already done to plain symbols, there can be TBinaryFunction and TBinaryVariable, as the function declaration can take its argument in infix-form.

[soulomoon]

Thank you @konn for the ideas! I've added it to the tracklist #3931

[michaelpj]

We even have a good LSP token type for this: operator.

[michaelpj]

Also, what about `isSubsetOf` vs +? Is the former also an operator or should it continue to be a function?

[konn]

We even have a good LSP token type for this: operator.

Indeed, as I already suggested in my solution section 😃

Also, what about `isSubsetOf` vs +? Is the former also an operator or should it continue to be a function?

Good catch. Both seem making sense, but I prefer treating it as a function provided that ` is not treated as a symbol name and coloured differently.

[soulomoon]

I realized, there is also a possible overlap here. take +, it is infix operator and class method.

[michaelpj]

Yep. I think you already have support for returning multiple types and picking one.

I note that there is a client capability for supporting overlapping tokens. I guess in principle that means we could return two tokens for the same span? I don't know what that would do.

[soulomoon]

I note that there is a client capability for supporting overlapping tokens

I suspect it is scarcely supported by clients.
e.g. Vscode decided not to support this. microsoft/vscode#147774

I am inclined to take precedency of class method over infix operator when it comes into conflict. What are you guys opinions on this?

[michaelpj]

I agree

[konn]

I note that there is a client capability for supporting overlapping tokens

I suspect it is scarcely supported by clients. e.g. Vscode decided not to support this. microsoft/vscode#147774

I am inclined to take precedency of class method over infix operator when it comes into conflict. What are you guys opinions on this?

I prefer it to be infix operator, but it is just a matter of taste. We might be able to make such precedence preference configurable, but that seems rather complex and non-ergonomic. After all, humans can tell the infix operators from plain class method as it consists of (non-letter) symbols. So, yes, treating it as class method seems making sense to me.