[Haskell] Annoying naming clashes

[Ben.Yu at combined.com]

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