-
-
Notifications
You must be signed in to change notification settings - Fork 388
semantic tokens: add infix operator #4030
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Changes from 2 commits
fb5317b
6908653
39b8d8a
4b0108c
30ced05
fc63b58
213896a
c174dc2
155d6cd
5dfdbb4
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,27 @@ | ||
4:1-3 TFunction "go" | ||
4:4-5 TFunction "f" | ||
4:6-7 TVariable "x" | ||
4:10-11 TFunction "f" | ||
4:12-13 TOperator "$" | ||
4:14-15 TVariable "x" | ||
6:2-6 TOperator "$$$$" | ||
7:1-2 TVariable "x" | ||
7:7-11 TOperator "$$$$" | ||
8:6-7 TTypeVariable "a" | ||
8:8-11 TTypeConstructor ":+:" | ||
8:12-13 TTypeVariable "b" | ||
8:16-19 TDataConstructor "Add" | ||
8:20-21 TTypeVariable "a" | ||
8:22-23 TTypeVariable "b" | ||
10:1-4 TFunction "add" | ||
10:8-11 TTypeConstructor "Int" | ||
10:12-15 TTypeConstructor ":+:" | ||
10:16-19 TTypeConstructor "Int" | ||
10:23-26 TTypeConstructor "Int" | ||
12:1-4 TFunction "add" | ||
12:6-9 TDataConstructor "Add" | ||
12:10-11 TVariable "x" | ||
12:12-13 TVariable "y" | ||
12:17-18 TVariable "x" | ||
12:19-20 TClassMethod "+" | ||
12:21-22 TVariable "y" |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,12 @@ | ||
module TOperator where | ||
|
||
-- imported operator | ||
go f x = f $ x | ||
-- operator defined in local module | ||
($$$$) = b | ||
x = 1 $$$$ 2 | ||
data a :+: b = Add a b | ||
-- type take precedence over operator | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I actually think people might prefer to see type operators highlighted differently? In "normal" Haskell syntax highlighting they are! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yeah, I've been thinking about this, may be it's better for us to mark all the infix thing as operator. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I feel reasonably sure that we want "operator" to take precedence over "type". I'm still unsure about "operator" vs "class method" There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. me neither, maybe we can make a pool or something to collect people's opinion on this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To be clear, I think it's fine for you to just make a decision for now, we can adjust based on feedback or add configuration. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yep, lets stick to the simplest way for now. Make the infix on top of all. |
||
add :: Int :+: Int -> Int | ||
-- class method take precedence over operator | ||
add (Add x y) = x + y |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since you're going to merge them all with
<>
later, perhapstyThingSemantic
should just return[HsSemanticTokenType]
, since in general we might allocate several types? That would simplify some things, e.g. here you're implicitly duplicating the fact thatTClassMethod
is preferred overTFunction
by putting the match forisClassOpId
first. (So if you ever changed the preference in the Semigroup instance you would still get the old answer!).So you could do something like:
and then let the semigroup instance sort it all out. Less important for the other cases where we don't have overlapping token types, though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True, let semigroup instance sort it all out would be better
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also you would actually have to do this if you wanted to make the priorities configurable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes, and it is going to be more tricky when priorities is configurable. Since we need to make sure the token type consistant between the one from hieAst and the one from typeThing.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, that should work out okay with the model where we just collect (possibly many) token types and then pick the "best". We'll have to have a "best" function that is derived from the configuration, instead of just the hardcoded one based on the Semigroup instance, but that seems okay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree, we might want to switch to list or set eventually with priorities configurations. Since by then, we might need to add test to ensure the all the results coming from imported or local names would have the same set of token types(instead of the current strategy to have just the same token type).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean if I have
then
foo
should have the same tokens in both cases? That does seem like a nice property!There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Exactly, we would have to have that property or the configuration would not work well.