-
Notifications
You must be signed in to change notification settings - Fork 17
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
Remember providence of Punned and Wildcarded named #86
Comments
which has problems, see haskell-suite/haskell-names#86
In the first case the information at 6:14 should be:
This should allow you to figure out that the local value Alternatively we could add more information to the In the second case the left-hand-side of the record field pattern should be resolved to a global symbol that refers to the record selector. |
Fair enough. I guess I was hoping to not have to keep track of any kind of environment for this renaming (which would allow me to do the renaming using a simple generic traversal instead of manually going through the AST), but maybe that is expecting too much.
Right – so that is a bug, isn’t it? |
Yes, should be fixed by #89 which also fixes the other bug you encountered. I am thinking about adding a field to In the meantime I can offer you two workarounds:
P.S.: Last time I tried to merge Haskell programs into one big module I got stuck because the |
Well, to do so in my case I need to know what module the
That might be the way to go. I did that by hand for now.
Luckily the itch I was scratching does not use |
I am using
haskell-names
to implement a simple renaming pass (including the module name in the symbol name), and I stumbled over a small lack of information on punned names.Consider
Here, the annotation I get for the use
field
inunRecord
isso it says it is a locally defined value bound at position 6:14, but the requirement that the name is equal to the name of the record field is lost. So if I rename the record field, the program fails to compile.
Even if I use non-local information and look at what’s at 6:14, I find
which is not very helpful.
Relatedly, if I change
..
tofield = field
, I findwhich says that the left
field
(the constructor field, at 6:14) is a local value bound at the position of the right namefield
(the variable, at 6:20), which is certainly wrong.The text was updated successfully, but these errors were encountered: