Difference between revisions of "Import modules properly"

From HaskellWiki
Jump to navigation Jump to search
(extracted from concatMapM discussion at Haskell-Cafe)
 
m
Line 20: Line 20:
 
In the second case, if new identifiers are added to the imported modules they might clash with names of other modules.
 
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.
 
Thus updating imported modules may break your code.
It may also be that <hask>Another.Important.Module.open</hask> was deprecated when you hided it,
+
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.
 
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!
 
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!

Revision as of 15:38, 17 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.

See also