On Wed, 16 Sep 2020, Ignat Insarov wrote:
### Explicit exports.
When there are no explicit exports, everything is exported from a module. Recall a case when this is disadvantageous: abstract types. The values of abstract types must only be obtained via smart constructors. So their definitions should not be made available. Explicit exports may provide that.
You can do the following in Cabal: Library private Exposed-Modules: A.Internal Library Exposed-Modules: A Build-Depends: private Test-Suite foobar-test Build-Depends: private This way you can export the constructors of a datatype from A.Internal and use them in A and in the test-suite, but the user of your package cannot access them.
### Explicit imports.
Recall the scenario in which explicit imports are useful.
* A module `"p" X` from package `p` imports a module `"q" Y` from package `q v0.0.0`. * The package `q` bumps the third version number and exports a definition `Y.d` which name coincides with an already defined definition `X.d`.
I would not distinguish between imports between modules from the same and from other packages, because in the course of refactoring you might want to split a package. Instead I write all my modules with qualified imports in mind, such that I can write e.g. Window.open instead of openWindow. E.g. 'containers' is a good pattern to follow.