Import modules properly: Difference between revisions
(debugging with explicit imports) |
(Prelude) |
||
Line 34: | Line 34: | ||
The test suite did miss that. | The test suite did miss that. | ||
== Exception from the rule == | |||
Since the Prelude is intended to be fixed for the future, | |||
it should be safe to use the <hask>hiding</hask> clause when importing <hask>Prelude</hask>. | |||
Actually if you do not mention Prelude it will be imported anonymously. | |||
== See also == | == See also == |
Revision as of 07:11, 28 May 2008
Haskell has a lot of variants of 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:
import qualified Very.Special.Module as VSM
import Another.Important.Module (printf)
instead of
import Very.Special.Module
import Another.Important.Module hiding (open, close)
Stylistic reason:
If you read printf
or VSM.open
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 Very.Special.Module
, Another.Important.Module
or even other modules.
Mind you that grep won't help, because Very.Special.Module
and Another.Important.Module
might just re-export other modules.
Compatibility reason:
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.
It may also be that Another.Important.Module.open
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 reason:
I once found a bug in the StorableVector package by converting anonymous imports to explicit imports.
I found out that the function Foreign.Ptr.plusPtr
was imported,
although functions from this module always have to calcuate with unit "element" not "byte".
That is, advancePtr
must be used instead.
Actually, the reverse
function used plusPtr
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.
Exception from the rule
Since the Prelude is intended to be fixed for the future,
it should be safe to use the hiding
clause when importing Prelude
.
Actually if you do not mention Prelude it will be imported anonymously.