[Haskell-cafe] Open unqualified imports

eyal.lotem at gmail.com eyal.lotem at gmail.com
Fri Jan 16 09:42:46 EST 2009


Hi,

I would like to suggest a change to Haskell prime's handling of
imports.

First, let me define a few terms:

Qualified import:
import qualified Data.Map [as Map]

Closed-unqualified import:
import Data.Map(Map, lookup)

Open-unqualified import:
import Data.Map

I believe that the last type, open-unqualified is a really bad idea,
and should be discouraged or even disallowed. It should definitely not
be the default, like it is today.

These are my reasons:

A) Most importantly, reading code that has even a few open unqualified
imports makes deciphering where names are coming from really
difficult.  The other two forms make it really easy.  Code is read
more often than it is written -- lets optimize for the reading case.

B) Code that has open unqualified imports may break when new symbols
are added to the libraries its importing.  This means that libraries
cannot even be considered backwards compatible if they retain
semantics, but add new exported names.

C) In my experience, Haskell modules can map their semantics to
standard type-classes such as Monoid, Functor, Applicative, etc.  This
means that many Haskell modules can do without exporting many names.
Sometimes, they can export no names at all (Only instances).  This
means that closed-unqualified imports often do just fine.  When there
are many exported names, qualified imports are good.

-----------------

I think currently many modules are designed to be imported
unqualified, and this is unfortunate. Haskell' libraries can fix
this.  For example, the various Monadic counterparts such as mapM,
replicateM, etc could do without the "M" in their names, and one could
use:

import qualified Control.Monad as M

M.for
M.map

and so on.

Additionally, I think there are some strong sentiments against the
choice of the function-composition dot as the qualified module name
lookup symbol.  It discourages people from using qualified imports.
Some other symbol ought to be used, but its not clear which symbol is
free.  Perhaps if unicode operators are allowed, then function
composition can move to the "right" symbol.

I believe qualified imports should probably have this syntax:

import Control.Monad as M

Closed-qualified imports can remain in the same syntax.
Open-qualified imports should probably be discouraged with a syntax
like:

import unqualified Control.Monad

And symbol clashes with these should probably just always choose the
overriding name.

Additionally, it would be nice if open unqualified imported were
considered quick&dirty enough for -Wall to warn that they generate
name clashes or are more difficult to read, to further discourage
them.

Eyal


More information about the Haskell-Cafe mailing list