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

[ozone at algorithm.com.au]

On 27/02/2004, at 3:47 AM, Keith Wansbrough wrote:

>> I've had an idea stewing in my head to do with per-type function
>> namespaces, that the current module namespace discussion reminded me
>> about.  The problem is that there is a limited namespace for 
>> functions,
>> so that if you define a new data type, it is unwise to call functions
>> which work on that data type a very generic name such as 'add'.
> [..]
>> 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.
>
> This feature would seem to be in competition with type classes; could
> you elaborate on the relative advantages and disadvantages?  The type
> class story has the advantage of being well understood and quite
> effective, but there are certainly some limitations too.

I don't think type classes can solve the problem I'm trying to tackle.  
As an example of why, check out the types of FiniteMap and Set's 'add' 
functions:

addToFM :: Ord key => FiniteMap key elt -> key -> elt -> FiniteMap key 
elt
addToSet :: Ord a => Set a -> a -> Set a

Note that the type of addToFM takes in two parameters (besides the 
FiniteMap itself): a key and an element, whereas the type of addToSet 
only takes in one parameter, which is the thing to add.  So, how can 
you come up with a type class which provides a polymorphic 'add' 
function, considering you don't even know how many parameters each data 
type's individual add function uses?

Even if you could define such a type class (which I don't think is 
possible), you then have one less function in the namespace to use, 
which is another problem.  For example, say I'm writing the 
Data.Complex module; there's a function in that module "phase :: 
RealFloat a => Complex a -> a".  So, how do you put this phase function 
into a type class?  Perhaps you could abstract away from the RealFloat 
and Complex bits, so you have a phase function which is generalised to 
work over a Num and an arbitrary data type instead; e.g. "class Phase c 
where phase :: Num a => c a -> a".  But what happens if, say, somebody 
adds a Moon data type, and they want to write a phase function which 
returns the phase of such a moon?  Phases of the moon certainly aren't 
Nums, nevermind the fact that you probably want to supply your moon 
phase's function with some sort of date as an extra parameter, which 
means the Phase type class isn't flexible enough.

Type classes are designed to provide a type-consistent interface to 
functions which perform different behaviour, unifying them as one 
function like + or == -- but it's designed to work for arbitrary types. 
  What I'm after is an interface for a function which may change 
depending on a "primary" type it's working with, which is almost the 
opposite to type classes.


-- 
% Andre Pang : trust.in.love.to.save