[Haskell-cafe] Are explicit exports and local imports desirable in a production application?
Ignat Insarov
kindaro at gmail.com
Fri Sep 18 08:38:13 UTC 2020
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.
More information about the Haskell-Cafe
mailing list