[Haskell-cafe] Correspondence between libraries and modules

[Ben Franksen]

Alvaro Gutierrez wrote:
> I've only dabbled in Haskell, so please excuse my ignorance: why isn't
> there a 1-to-1 mapping between libraries and modules?
> 
> As I understand it, a library can provide any number of unrelated modules,
> and conversely, a single module could be provided by more than one
> library. I can see how this affords library authors more flexibility, but
> at a cost: there is no longer a single, unified view of the library
> universe. (The alternative would be for every module to be its own,
> hermetic library.) So I'm very interested in the rationale behind that
> aspect of the library system.

I am probably repeating arguments brought forward by others, but I really 
like that the Haskell module name space is ordered along functionality 
rather than authorship. If I ever manage to complete an implementaton of the 
EPICS pvData project in Haskell, it will certainly inherit the Java module 
naming convention and thus will contain modules named Org.Epics.PvData.XXX, 
*but* if I need to add utility functions to the API that are generic list 
processing functions they will certainly live in the Data.List.* name space 
and if I need to add type level stuff (which is likely) it will be published 
under Data.Type.* etc. This strikes me as promoting re-use: makes it far 
easier and more likely to factor out these things into a separate general 
purpose library or maybe even integrate them into a widely known standard 
library. It also gives you a much better idea what the thing you export is 
doing than if it is from, say, Org.Epics.PvData.Util. Finally, it gives the 
package author an incentive to actually do the refactoring that makes it 
obvious where the function belongs to, functionally.

Cheers
Ben