[Haskell-cafe] Re: Open unqualified imports

[Eyal Lotem]

On Fri, Jan 16, 2009 at 4:42 PM, eyal.lotem at gmail.com
<eyal.lotem at gmail.com>wrote:

> 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:

Correction:

Closed-unqualified imports can remain in the same syntax.
Open-unqualified 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

imported -> imports

>
> considered quick&dirty enough for -Wall to warn that they generate
> name clashes or are more difficult to read, to further discourage
> them.
>
> Eyal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090116/bc6899c9/attachment.htm