Closed Lysxia closed 7 years ago
Interesting. I am comparing the current implementation to the one in https://www.cs.kent.ac.uk/projects/refactor-fp/publications/Huiqing-thesis.pdf, and I see the in-place checking for each occurrence has got lost somewhere along the way.
In particular
"Inside the function condChecking' , three conditions are checked. The first condition ensures that the new name does not exist in the same binding group, where the function declaredVarsInSameGroup (from the API) is used to fetch all the variable names declared in the same binding group where x is declared. The second condition checks whether the new name will intervene between the existing uses of y and its bindings, where function hsFreeAndDeclaredNames is used to fetch the free and declared variables in the argument syntax phrase. The third condition checks whether the new name is declared somewhere between the declaration of identifier to be renamed and one of its call-sites, and function hsVisibleNames is used to collect the names which are declared in the given syntax phrase and visible to one of the call-sites of the identifier. In the local functions, including inMatch, inPattern, and inAlt , the values defaultPNT and/or [ ] are used to shadow those variables declared in the same syntax phrase but in an outer scope."
Looks like a complete revalidation against the original will be required, for the various refactorings.
Rename
x
tog
is successful, but shouldn't be as the result is not equivalent: