I would like to summarize the conversation so far. Surely I am not free from bias, so please object if my representation of some of the opinions I am re-stating is unfair or incomplete to their disadvantage. I shall present arguments and counter-arguments in the shape of a tree, with markup and indentation. ### Many people said that they like qualified imports. Note that my opening message did not speak against that. I suppose I should have stated openly that I am all for appropriate use of qualified imports with descriptive names, such as `Text.pack`, `Set.fromList` and even `List.sort` — although `Maybe.fromMaybe` may be be too much. I think there is wide agreement about this. ## Imports. ### Reasons why explicit imports may be preferable: * Resolution of names to the originating modules. - Note that this still leaves it to the reader to resolve modules to packages. That is, unless one also insists on using package imports, which I see very rarely. - Modern tools can resolve names as if by magic, qualified or not. Surely we can expect more progress in this direction. * Can we expect online, multilingual code repositories to do this for us? ### Cases when explicit imports are required: None so far. _(Disambiguation can be done with qualified imports.)_ ## Exports. ### Reasons why explicit exports may be preferable: * There may be a helper function that is used by several exported functions, so it cannot be put in a `where` clause — if it is absent from the explicit export list, GHC will be able to optimize better. * Haddock magic: changing the order of exports, adding headers and sections. - Most if not all of these effects can be accomplished without export lists. * Detection of dead code by GHC. - Tools exist to detect dead code without the use of explicit exports. ### Cases when explicit exports are required: * Exporting the type constructor of an abstract type, but not its data constructors. * Re-exporting modules.