Skip to content
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

False positive shadowing when reviewing Typed Racket code? #10

Open
jessealama opened this issue Mar 1, 2021 · 2 comments
Open

False positive shadowing when reviewing Typed Racket code? #10

jessealama opened this issue Mar 1, 2021 · 2 comments

Comments

@jessealama
Copy link

jessealama commented Mar 1, 2021

Take a look at this Typed Racket code:

#lang typed/racket/base

(provide do-it)

(: do-it (-> (Listof Number)
             (List (Listof Integer)
                   (Listof Integer))))
(define (do-it nums)
  (define evens (filter (lambda ([n : Any]) (and (integer? n) (exact? n) (even? n)))
                        nums))
  (define odds (filter (lambda ([n : Any]) (and (integer? n) (exact? n) (odd? n)))
                       nums))
  (list evens odds))

Putting aside that this code doesn't quite pass the type checker, what's puzzling is that when this code is passed through review, it generates a warning:

mini.rkt:11:34:warning:identifier 'n' shadows an earlier binding

This seems wrong to me. Sure, there are two lambdas there with the same formal parameter, but the second one surely doesn't shadow the first. It's not even in the same scope.

When you turn this into a plain Racket module, review doesn't complain.

It seems to me that TR is either rewriting the code before review sees it, or perhaps there's an issue somewhere in review? Do you have some advice for getting rid of this warning?

@Bogdanp
Copy link
Owner

Bogdanp commented Mar 13, 2021

Typed Racket isn't really supported by review because review doesn't expand the code it lints, so I'd have to bake in a bunch of typed-racket-specific rules into it and I don't know if I'd want to do that because I don't use TR atm.

@jessealama
Copy link
Author

Thanks for thinking about this. I realize TR is a bit off the radar for review. I'm also willing to take a look at the issue and see if I can fix it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants