Google for "per-type function namespaces", which was an idea I sent to the list a few months ago, for something which I think better solves the naming issue. Quite a lot of people disagreed with it, but I still think it's a good idea. (FWIW, I nearly managed to implement this with Template Haskell, but I couldn't work around the restriction that you couldn't splice in a TH function declared in the same module.)
Andrei, I just skimmed through the "per-type namespace" thread. I'd say besides the ability to do overloading with type classes, I do like what they called ad-hoc polymorphism. And that is by no means the type classes can support. By "ad-hoc", we mean we don't know who the heck will create a function with the same name with whatever parameters and in whatever modules, classes. If you create a type class to mean "well, this name may be used by different module for god-knows different things", that feels awkward. And theoretically, any name can be duplicated. Do we create a class for every function names we create? And there's naming problems for type class operations too. When you create classes, how do you name operations? If you name your operation happily as "get", how are you sure that somebody else will not want to use this name for his own functions or class operations? Actually, to me, it is the naming clash for class operations that bothers me the most. For the alternatives people present so far, I don't see any of them satisfactory. 1. Use small modules. Yes. I can use small modules. But I will somewhere need to use more than one modules. And it is very possible that two names from two modules that I import clash. Also, even not able to use the same name within one module is sometimes annoying too. Split this module into 2 sub modules? I suppose modules are designed for seperating natural modules, not for seperating duplicate names. Creating a module just to get some synonym out sounds quite ad-hoc design. OO languages, on the other hand, even within the same class/interface, we have overloadings, we can create nested classes that brings its own namespace. Very rarely do I need to worry about name clashes. I can name functions as nicely as I can come up with. 2. Use qualified name. Well. that is a systematic solution. But, if I know I'll have to almost always write MySomeModule.add, I probably would want to name it "addMSM" to make it short, as what FiniteMap is doing. I like the code example that Oleg presented in your thread, and I love the Haskell type system that can even support overloading by returns, very powerful indeed. However, they are parametric polymorphism, even though they can to some extent simulate ad-hoc polymorphism, I just don't see they are the right tool to support ad-hoc polymorphism. In summary, names may seem a cosmetic issue. What is the fundamental semantics and functionality differnce between "add" and "MyModule.add" anyway? Just a few keystrokes, right? However, IMHO, naming is the very fundamental cosmetic issue, as in most programming languages. Not being able to name things freely is a big problem in my eyes. This message is intended only for the addressee and may contain information that is confidential or privileged. Unauthorized use is strictly prohibited and may be unlawful. If you are not the intended recipient, or the person responsible for delivering to the intended recipient, you should not read, copy, disclose or otherwise use this message, except for the purpose of delivery to the addressee. If you have received this email in error, please delete and advise us immediately.