On Thu, Sep 17, 2020 at 3:08 PM Isaac Elliott
I don't think that it's unreasonable in general to expect people to explore a codebase via IDE tooling. But given Haskell's current situation on that front, I currently agree with your approach to Haskell imports/exports.
Ignat, I agree with you that explicit imports/exports involve unnecessary typing. I call this "busywork". Explicit exports still seem valuable for encapsulation, avoiding name clashes, and in the case of GHC they unlock a bit more optimisation.
In this case I think that we should automate that busywork, and hopefully the recent Haskell IDE work gives us a path in that direction.
I mention this every time it comes up, but you can automate it right now, and I've been doing it for the last 10 years or so, no IDE needed. The tool I wrote is called fix-imports, but there are a number of others floating around. So I don't agree that writing imports is busywork, you never had to write that stuff in the first place, if you really didn't want to. Another benefit of qualifications for navigation is that they can disambiguate tags. Fancier IDE-like tools could do that without the qualification, but tags are here now and I think they actually work better. Actually on further thought, the same thing that disambiguates based on qualification could also easily disambiguate without it, so maybe this is not a real benefit after all. I just happened to set up the former and not the latter :) My first step looking at any third-party code is to tags the whole lot but for whatever reason I still much prefer qualifications. Few people use them though. For explicit exports, I often leave them off for convenience during development, but put them in when it settles down. I don't think it unlocks any optimization in code generation, but it does make rebuilds faster because it won't change the hi file if you changed a non-exported non-inlined function. You also get unused warnings. When I add the export list, I often append '#ifdef TEST , module This.Module #endif' so that tests still have total visibility. I prefer this to the Internal module approach because I don't like zillions of modules with the same name, and I don't want to have to structure code to the whims of tests, and I like to get unused symbol warnings from ghc without having to go to weeder. One benefit to explicit exports that surprises me is the trivial detection of unused functions. On several occasions I have done extra work or even just extra thinking to try to preserve a caller, only to find out that due to the changes I just made, it has no other users and I could have just deleted it without thinking hard. Yes, a simple grep would have revealed that, but I will instantly notice ghc saying unused symbol and I might not think to insert manual greps into my planning process. Often it's a whole chain of callers that can be deleted, and ghc will find those all immediately.