[Haskell-cafe] What's in a name?

[Andrew Coppin]

Henning Thielemann wrote:
> Although it is possible to hide packages by GHC options, we should not 
> do this, because several libraries might use different Hash tables and 
> it would not be possible to write a program which uses many of these 
> libraries. It's better to add a distinguishing part to the module 
> name, like Data.HashTable.Coppin or so.

This is more the sort of thing I had in mind, yes.

As others have pointed out, not everybody has a domain name, so Java's 
technique of inserting a domain name perhaps isn't the best one. 
However, if we all agreed that, say, packages should be named 
"coppin-hashtable" or something, then there wouldn't be much danger of 
ambiguous package names. (As I already pointed out, there's at least 3 
packages called "bianry", which is just confusing.) It's rather less 
clear what to do with something like, say, ByteString, which is the 
product of a large number of collaborators. Then again, it's a big 
enough package that nobody is likely to come up with a similar one. 
(Unless it's a fork I suppose - in which case a prefix or suffix for the 
person who forked it might be appropriate?)

What to do at the module level is less obvious. Having several packages 
provide different implementations of the same thing is arguably useful. 
(E.g., I know Gtk2hs provies an SOE module. What about wxHaskell? If the 
interface is standard enough, a given application might not actually 
care which implementation it gets.) I'm open to suggestions here...

I don't claim to have all the answers. I'd just like to see some debate 
happening. ;-)