Skip to content
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

Don't use symbols in Crystal::Lexer#check_macro_opening_keyword #13277

Conversation

HertzDevil
Copy link
Contributor

No description provided.

@@ -1966,7 +1966,7 @@ module Crystal
elsif !delimiter_state && whitespace && (keyword = lookahead { check_macro_opening_keyword(beginning_of_line) })
char = current_char

nest += 1 unless keyword == :abstract_def
nest += 1 unless keyword == {Keyword::ABSTRACT, Keyword::DEF}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Considering that this seems to be the only use of check_macro_opening_keyword's return value, wouldn't it be sufficient to return true/false to indicate whether to increase nesting? 🤔

Copy link
Contributor Author

@HertzDevil HertzDevil Apr 4, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The truthiness is also used, there'll need to be at least 3 distinct return values. And I don't think repurposing Bool? for this looks good

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There might be a way

@Sija
Copy link
Contributor

Sija commented Apr 4, 2023

What's the point of replacing symbols with named tuples?

@straight-shoota straight-shoota added this to the 1.9.0 milestone Apr 18, 2023
Copy link
Member

@straight-shoota straight-shoota left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actually, after thinking about this again I'm not convinced about using a named tuple here just to signal three states.
IMO Bool? would be fine. Maybe not ideal for mapping the different values. Perhaps semantics would improve by renaming the method to keyword_at_macro_start_is_abstract_def?: nil means there is no keyword at macro start, false means the keyword is not abstract def and true means it is.
More fancy modeling is possible but unnecessary for the current usage.

@straight-shoota straight-shoota removed this from the 1.9.0 milestone Apr 19, 2023
@HertzDevil
Copy link
Contributor Author

false would interfere with the way #lookahead works (any falsey value causes backtracking, and the other uses of #lookahead do return false), so there still need to be two distinct truthy states. I was originally going for a private enum at first but it seems even more overkill than the NamedTuple here.

@straight-shoota
Copy link
Member

straight-shoota commented Apr 24, 2023

Thanks for clarification. Makes sense.

I'm not happy about using a named tuple, though. We're usually preaching their purpose is for named arguments and it's not recommended for anything else.
Maybe we can use a record instead? That's basically the same except that we need a line to define the type. But that's all.

Another alternative would be a singleton value as a second truthy state.
But expressing the same data structure as a record instead of a named tuple should be better.

@beta-ziliani
Copy link
Member

I disagree with the idea that NamedTuple is only for named args 😅 I think of NamedTuple as an anonymous record, and I don't see a problem with it.

@straight-shoota
Copy link
Member

@beta-ziliani I don't think we're using named tuples anywhere like that (and IMO for good reason). Instead, we have dozends of simple record types in the compiler source. We should do that here as well.

@HertzDevil
Copy link
Contributor Author

What about:

private enum MacroKeywordState
  AbstractDef
  Other
end

@straight-shoota
Copy link
Member

I figure a record might be more flexible should there ever be a need for additional information.
But either is fine by me.

@straight-shoota straight-shoota added this to the 1.9.0 milestone Jun 5, 2023
@straight-shoota straight-shoota merged commit 9d86367 into crystal-lang:master Jun 7, 2023
46 checks passed
@HertzDevil HertzDevil deleted the refactor/check_macro_opening_keyword branch June 16, 2023 19:21
Blacksmoke16 pushed a commit to Blacksmoke16/crystal that referenced this pull request Dec 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants