More refactoring ideas

[jackfirth]

The bare bones of resyntax are working, though not very well. It can refactor code by using refactoring rules written with the syntax-parse macro system like so:

(define-refactoring-rule vector-immutable/c-migration
  #:literals (vector-immutable/c)
  [(vector-immutable/c c ...)
   (vector/c c ... #:immutable #t)])

At this time, the most effective way for people other than me to contribute is to look at real world code written in #lang racket/base for potential refactorings that resyntax could suggest. An ideal refactoring rule meets the following criteria:

• Obviously correct. A human who blindly applies the resyntax tool to their codebase shouldn't have to worry about individual refactorings breaking anything.
• Non-controversial. For example, refactorings that remove uses of deprecated forms are good candidates, refactorings that make code stylistically better in subjective ways are not. Bonus points for refactorings that can point to documentation explicitly stating why the refactored code should be preferred.
• Self-contained. A refactoring rule should not be a whole-program transformation, and it should not require any global knowledge of the codebase. Refactoring rules should not depend on other rules to clean up messes they create.
• Occurs "in the wild". I want to focus on rules that solve real problems in real code, not hypothetical problems in hypothetical code. When suggesting a rule, please include links to existing code that the rule could clean up.

If you have a large Racket codebase with lots of old code that needs cleaning up, I would love to hear from you!

[jackfirth]

Note to self: move this information into the Resyntax documentation.