View source for Import modules properly

== Introduction ==

Haskell has a lot of variants of [[Import|importing]] identifiers from other modules.
However not all of them are as comfortable as they seem to be at the first glance.
We recommend to focus on the following two forms of import:
<haskell>
import qualified Very.Special.Module as VSM
import Another.Important.Module (printf, (<|>), )
</haskell>
instead of
<haskell>
import Very.Special.Module
import Another.Important.Module hiding (open, close, )
</haskell>

There are four different kind of reasons for this.

* '''Style:''' If you read <hask>printf</hask>, <hask><|></hask> or <hask>VSM.open</hask> in the program you can find out easily where the identifier comes from. In the second case you don't know if these identifiers are from <hask>Very.Special.Module</hask>, <hask>Another.Important.Module</hask> or even other modules. Mind you that grep won't help, because <hask>Very.Special.Module</hask> and <hask>Another.Important.Module</hask> might just re-export other modules. You might guess the origin of <hask>printf</hask> according to its name, but for the infix operator <hask><|></hask> you will certainly have no idea.
* '''Compatibility:''' In the second case, if new identifiers are added to the imported modules they might clash with names of other modules. Thus updating imported modules may break your code. If you import a package A with version a.b.c.d that follows the [[Package versioning policy]] then within versions with the same a.b it is allowed to add identifiers. This means that if you import the suggested way, you can safely specify <code>A >= a.b.c && <a.b+1</code> in your [[Cabal]] file. Otherwise you have to choose the smaller range <code>A >= a.b.c && <a.b.c+1</code>. It may also be that <hask>Another.Important.Module.open</hask> was deprecated when you hid it, and with a module update removing that identifier, your import fails. That is, an identifier that you never needed but only annoyed you, annoys you again, when it was meant to not bother you any longer! The first variant of import does not suffer from these problems.
* '''Correctness:''' I once found a bug in the StorableVector package by converting anonymous imports to explicit imports. I found out that the function <hask>Foreign.Ptr.plusPtr</hask> was imported, although functions from this module always have to calculate with unit "element" not "byte". That is, <hask>advancePtr</hask> must be used instead. Actually, the <hask>reverse</hask> function used <hask>plusPtr</hask> and this was wrong. A misbehaviour could only be observed for sub-vectors and elements with size greater than 1 byte. The test suite did miss that.
* '''Maintenance:''' All too often I find an old module that cannot be compiled any longer since it uses identifiers that do no longer exist. If the module imports implicitly and without qualification I have little chance to find out where the identifiers originally came from, what they meant and how they must be replaced.