search

jackfirth / resyntax

A Racket refactoring engine
Apache License 2.0
56 stars 10 forks source link

Suggest using `in-inclusive-range` instead of `in-range` #153

Open jackfirth opened 2 years ago

jackfirth commented 2 years ago

This code:

(for ([x (in-range a (add1 b))])
  body ...)

Can be refactored to this:

(for ([x (in-inclusive-range a b)])
  body ...)

See this discussion with @sorawee for some tricky details:

notjack okay so in-inclusive-range is harder than I thought to handle correctly, because when it's used directly in a for form the (in-inclusive-range ...) expression is never actually seen by the macro expander. the for macro rips it apart before the expander ever sees it. and resyntax searches for expressions to rewrite by observing the macro expander's behavior, so it can't see them. sorawee Oh, I still thought that Resyntax only analyzes surface syntax. That's not the case anymore? This is very cool notjack resyntax analyzes every expression that appears during macro expansion, though it only tries to apply rules to syntax-original? expressions - that's why resyntax can refactor things correctly even in the face of renamings and shadowings the downside is that if an expression is invisible to the expander, then it's invisible to resyntax as well in theory maybe it could work to reuse the disappeared uses information that macros emit for check syntax to figure out that some expressions are part of the program even though they're never expanded sorawee FYI: Typed Racket has a functionality to recover correspondence between surface and expanded code. Not sure if it will be helpful to you. https://github.com/racket/typed-racket/blob/master/source-syntax/source-syntax.rkt notjack oh cool that's neat! that might help to go from an in-range identifier in a disappeared uses property to its enclosing (in-range ...) expression