-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Add TASTy Reflect Pattern.Wildcard #6275
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
Add TASTy Reflect Pattern.Wildcard #6275
Conversation
|
This inconsistency was discovered while implementing #6274 |
da6bc89 to
7ff2fee
Compare
liufengyun
left a comment
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.
Otherwise, LGTM
|
|
||
| /** Pattern representing a `_` pattern */ | ||
| type Wildcard = kernel.Wildcard | ||
|
|
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.
A little concern for flattened Pattern names: Wildcard has different meanings in different places, it may cause confusion.
Maybe WildcardPattern -- as most macros will not touch patterns, a long name will not affect usability.
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 renamed it to WildcardPattern
Wildcard are represented with Ident but are not valid terms. The current API exposed them an the contens on a Pattern.Value which advertives them as Terms. To avoid we add Pattern.WildcardPattern and stop returning them from Pattern.Value.
7ff2fee to
59e378a
Compare
liufengyun
left a comment
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.
LGTM
| def unapply(pattern: Pattern)(implicit ctx: Context): Boolean = | ||
| kernel.matchPattern_WildcardPattern(pattern).isDefined | ||
| } | ||
|
|
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.
Minor (no need to address in this PR): we could use just Wildcard here, as there is no worry for conflict or confusion.
Maybe we can avoid flattening types for seldomly used categories like TypeTrees and Patterns to reduce conflicts and confusions.
Wildcard are represented with Ident but are not valid terms. The current API exposed them an the contens on a Pattern.Value which advertives them as Terms. To avoid we add Pattern.Wildcard and stop returning them from Pattern.Value.