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 _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
