Re: [Haskell-cafe] Design your modules for qualified import

Excerpts from johan.tibell's message of Mon Jun 09 21:53:50 +0200 2008:

On Mon, Jun 9, 2008 at 4:04 PM, Ketil Malde wrote:

...

I think designing modules for qualified-only use is a mistake. I also think import lists get quite ugly, with multiple instances of

I was only suggesting avoiding namespacing prefixes/suffixes in identifiers. Other than that things would be the same. You don't have to import things as qualified. However, if you're going to try to avoid using identifiers in your exported interface because they would collide with other modules I would advice against it. I agree with you that the module imports get a bit ugly. I prefer that to the alternative though.

...

Add to this that people will assign a variation of abbreviations for modules, we quickly lose consistency.

It's a shame that we have such deep hierarchies otherwise we wouldn't need to always alias out module imports. I think Python get's it right:

import os

... os.tmpname ...

Duncan's recommendation of just taking the part after the last dot seems like a good rule of thumb. Doing

import qualified Data.Map as M

does gain you much in my opinion. Compare M.empty to emptyM. No difference, you still can't deduce the module by just looking at the call site.

Coming from a world where qualified names at call sites or full import (open) are the default rules (OCaml), I much prefer the import way (where you specify names that gets imported) and thus prefer when names don't collide (except for modules like Data.Map or ByteString where I use the "as" notation). The key point for me is to be able to trace as fast as possible what precisely use a module by looking (only) at the top of the file. Best regards, -- Nicolas Pouillard aka Ertai