-
Notifications
You must be signed in to change notification settings - Fork 197
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
Fix/rewrite Scope.hs #1001
Comments
Agreed! Scope needs a significant overhaul and performance improvements too. There are increasingly more tickets which are scope bugs. I'll create a label for them. |
Plan of attack is probably first to figure out what the semantics of the "perfect" scope module are, then how to implement that efficiently, then finally implement it. |
Here's an initial outline of the Scope problem. Throughout, I use name to mean things like Hint Scope
Module Scope
Operations
Efficiency
|
Thanks @ndmitchell! One possible way to make hint scopes more accurate and configurable is to put the scope information in a separate # scope.yaml
- mapM: [Prelude, Control.Monad, Data.Traversable]
- forM: [Control.Monad, Data.Traversable]
- forM_: [Control.Monad, Data.Foldable] Multiple occurrences are allowed, e.g., there may be another - forM: [Data.Vector] Such information can already, for the most part, be encoded in the current yaml config. However, as we can see, Moreover, having a
A possible syntax for overriding is Control.Monad.forM: [+, Foo.Bar] # add a module
Control.Monad.forM: [-, Data.Traversable] # remove a module
Control.Monad.forM: [Control.Monad, Data.Traversable, Foo.Bar] # reset the modules (if there's only one Multiple scope config files can be passed to HLint. The later ones override the earlier ones (i.e., each one is a "delta" wrt the previous one). |
Interesting idea - it would be very desirable to not have to add a |
I don't see any reason for a separate file - we can just introduce The idea of |
It seems this is currently possible but not easy. For example, if I want to change the
On the other hand, by separating scope yaml from rule yaml, you can simply swap the original scope.yaml for your own.
Yeah, so to encode - mapM: [Prelude, Control.Monad, Data.Traversable]
- forM: [Control.Monad, Data.Traversable]
- forM_: [Control.Monad, Data.Foldable] using imports, it'd probably look like import Prelude (mapM)
import Control.Monad (mapM, forM, forM_)
import Data.Traversable (mapM, forM)
import Data.Foldable (forM_) The advantage of the former is that it immediately follows that |
If people swap a scope.yaml for their own, then they stop getting bug fixes from HLint. It would be much better for people to specify overrides, and once you're doing that, I don't see the need for a separate file. |
I'd love to learn about how overrides are specified (or will be specified). In my work repo there's a custom prelude |
My guess would be users specify that in their |
The way Scope.hs behaves is fairly erratic. For example:
I guess a name should be assumed, if there's no other source of information, to come from Prelude. With this assumption, in the second case it should be able to suggest
Prelude.mapM
, and in the third case it should know thatData.Int
is irrelevant.The text was updated successfully, but these errors were encountered: