[Haskell] Per-type function namespaces (was: Data.Set whishes)

[David Bergman]

Mr. Ozone wrote: 

[snip]
> So at the moment, many Haskellers will append the type name to the 
> function to indicate that it only works on that particular data type.
> In this respect, Haskell is at a disadvantage vs most object-oriented 
> languages, because in them, you can write "x.add", and the type system 
> will perform "object-oriented polymorphism" for you and call the 
> correct add method, no matter if x is a FiniteMap or a Set.  Writing 
> "addToFM fm ..." or "addToSet set ..." is surely a lot more 
> inconvenient than writing "fm.add" or "set.add", no?

Yes. But, you are refering to overloading, no? And, not subtype polymorphism
(which is what I denote with "object-oriented polymorphism")? Just to make
things clear in my mind.

> The idea that I've been throwing around is to be able to define a 
> separate namespace for each type; a function can either belong in a 
> "global" (default) namespace, or belong in a particular type's 
> namespace.  So, in the above example, instead of writing "addToFM fm 
> ...", we could instead associate an 'add' function with the FiniteMap 
> type, so we could write "fm.add ..." instead.  Provided that fm's type 
> is monomorphic, it should be possible to call the 'correct' add 
> function; if we defined another 'add' function that's associated with 
> the Set type, that will only get called if the 'x' in "x.add" is of 
> type :: Set.  So, like OO languages which inherently give separate 
> namespaces to their different objects, here we give separate 
> namespaces to different
> (monomorphic) types.  In this case, if one simply writes "add" instead 
> of "x.add", the compiler throws an error, because there is no 'add' 
> function defined in the default namespace; add is only defined when a 
> programmer writes "x.add" where x :: FiniteMap or x ::
> Set[1].

This overloading by namespace is usually called either ADL
(Argument-Dependent Lookup) or Koenig Lookup (especially in C++.)

So, you have thought of automatically, but implicitly, introduce a namespace
for each data type, and then have Haskell employ Koenig Lookup, to decide
which function an expression is refering to?

You realize, of course, that "mere" intranamespacial parameter type lookup
(regular overloading) would achieve the same effect, without the (implicit)
namespaces?

The core problem in Haskell is to bypass the generics, i.e., make sure that
a certain definition is used for a certain type, or combination of types.
This can only be done by class instances, as of now, but there have been
discussions of non-class overloading.

> There are a number of means by which the x in x.add can be 
> communicated to the actual function: it's similar to the hidden 'self' 
> or 'this'
> variable that's present when you invoke a method on an object in OO.  
> Perhaps x is passed to the function as its first parameter, or maybe 
> it could be its last parameter, or even an arbitrary parameter (where 
> the parameter it's passed as could be defined in the type signature of 
> the function).  Perhaps 'self' or 'this' could be an implicit 
> parameter.
> Any one of them will work just fine, I think.

Again, I think you are confusing the runtime dispatching subtype polymorpism
from overloading. Overloading would do what you want, while the subtype
polymorphism could (still) be handled by class, and instances of classes,
the Generic Programming way.
 
/David