-
Notifications
You must be signed in to change notification settings - Fork 26
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
Made constDecDef
capitalize constants in Python
#3858
Changes from 3 commits
034a0e4
c55c83b
4523e43
d64407c
77bbe0a
524be4e
098c8d8
b721a99
4f29096
c5d05e7
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
Some generated files are not rendered by default. Learn more about how customized files appear on GitHub.
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.
Do we want this to be an error? We could just warn the user and potentially just use the lowercase version of it (assuming that it is available)…
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.
That's a good point. It would be better to do it that way. The only thing I'm not sure about is, how do we keep track of whether or not the renderer used the modified name? When the
constant
function shows up later, it needs to know whether or not to modify the variable name.varNameAvailable (variableName v')
- if the original name was used, we can probably assume that it was used for the constant in question, else we must have modified it. This would work, but it feels a little sketchy to me.constant
function, we could look up the name to use, and not have to worry about any misplaced assumptions. This would be a bit of extra work to implement, though.What are your thoughts? I'd rather not do option 2 until @JacquesCarette can take a look. Would it be better to do option 1 for now, as it should be a small change?
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.
As a side note, what's the best way to print a warning in Haskell? I'm not actually sure if there's anywhere else in GOOL that currently prints warnings. It seems like a shame to wrap all of GOOL in
IO String
just for this, is there a better way?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.
Honestly, I'm thinking that "error vs. warning" may be a variability we'd want to introduce at some point. Since this is likely going to be a bigger change, I would create a new issue for tracking our design decisions and working on it in a separate PR (if at all!)
No idea about your warning question 😅