Skip to content
This repository has been archived by the owner on Mar 11, 2020. It is now read-only.

[IMRF-5] Figure out how to detect unused instances #43

Open
chshersh opened this issue Aug 11, 2017 · 0 comments
Open

[IMRF-5] Figure out how to detect unused instances #43

chshersh opened this issue Aug 11, 2017 · 0 comments
Labels

Comments

@chshersh
Copy link
Contributor

Currently we don't do this because importify is parsing-only tool. Our decision about detecting instances provided below:

Options we have regarding detecting unused instainces:

  1. Parse stack build result or other build result. Well, it's not actually an option because we don't want to compile package...
  2. Parse ghci results. There's ghcid — ghci daemon which runs and interprets haskell files on-the-fly after every change. It's really lightweight. Maybe we can use and write something similar to find such errors w/o compiling, only interpreting.
  3. Use ghc-mod . I don't how it works. But it provides ability to get information about compiler warnings. Maybe it compiles whole project or uses already compiled cache and does something smart. Maybe this tool can be used to find these kind of warnings. Good news is that we only need to run not many times than once per every import line entry (but that's also really painful)
  4. Well, just ignore this 😄 It's really rare case where imports like import Control.Monad () occur in existing library. If so, programmer uses orphan instances which is a bad idea. If not — he can remove such lines by his own. So we can just ignore imports with already empty () . If import list become empty after removing functions – well, it's also really rare case. Because you really rare use only instances, you use mostly some methods and types. So this is very unlikely that () import should be kept after removing all functions. Like, maybe we don't want to complicate tool because of programmer fails and import syntax fails.

Ok, so "if you do something weird it should be apparent in the code". 😄

For now option 4 is chosen.

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

No branches or pull requests

1 participant