Suggest using in-inclusive-range instead of in-range

[jackfirth]

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

[jackfirth]

Found a tricky case that the 'disappeared-use strategy can't solve:

(let-syntax ([add1 (syntax-rules () [(_ x) x])])
  (for ([i (in-range 1 (add1 5))])
    (displayln i)))

The add1 is shadowed, so this isn't safe to refactor to in-inclusive-range. However, to tell that it's shadowed, we need to analyze the #'(in-range 1 (add1 5)) syntax object with the scopes that were present on it at the time the expander visited it indirectly via the for expression. We can't rely on Resyntax's existing logic to reconstruct scopes from fully expanded code, because the add1 identifier in the (in-range 1 (add1 5)) expression won't appear in the fully expanded code.

[jackfirth]

I've got a working implementation of this rule that relies on a patch to Racket to add a 'disappeared-visit property.

[jackfirth]

See also #369.