Too many import lists: let's make names unique and drop same-package import lists

[ezyang]

I've recently done several refactors on the Cabal code base (moving around some core fields in order to make things cleaner, etc) and I've noticed the single biggest annoying thing about doing this is fixing up the import lists. EVERY SINGLE TIME. It is driving me completely batty, and wasting so much of my time.

I want to kill it with fire. Specifically:

1. I'll delete every explicit import list in Cabal.
2. Whenever there is a conflict, I'll disambiguate by renaming the identifiers to something unique, so that given any name, there is exactly one definition in Cabal.

I want some people to agree that we should do this, and then I'll do it.

[gbaz]

I also don't like the explicit imports everywhere style, found it irritating to work with, and am cool with this. But I am only an occasional cabal hacker, so I conformed to convention. This sort of thing should be decided by those who most frequently hack on the code since it matters most to their quality of life, so my opinion doesn't matter much here. That said, 👍

[23Skidoo]

I find them useful for code navigation. M-<; C-f foo tells you where foo came from.

Whenever there is a conflict, I'll disambiguate by renaming the identifiers to something unique.

Can be controversial for data structure-like things, e.g. Foo.{new,foldWithKey} vs newFoo,foldFooWithKey.

/cc @dcoutts

[ezyang]

@23Skidoo I personally use hasktags to do code navigation. This works really great for same-project since the tags file is then pretty comprehensive.

If it's data structure like, I expect that it will be imported qualified and won't induce a conflict rename.

[ttuegel]

Can be controversial for data structure-like things, e.g. Foo.{new,foldWithKey} vs newFoo,foldFooWithKey.

In principle, I agree with disambiguating names wherever practical, but I don't want to see us in a situation like this.

[ezyang]

@ttuegel To be clear, I am NOT proposing to rename data structure names. (GHC does have the qualified style but I think it's uncommon in the broader library ecosystem)

@beni55 I don't understand your comment.

[tibbe]

No, we should use namespaces and not ad-hoc prefixes. One way to make this less annoying is to just import qualified and then use Module.foo.

[ezyang]

OK, so I guess then an alternate proposal is to:

1. Delete every explicit import list in Cabal
2. For every conflict, explicitly qualify one (or more) of the conflicting modules

[ttuegel]

👍 I think that will already be a big improvement.