[Haskell] Per-type function namespaces (was: Data.Set whishes)
ozone at algorithm.com.au
ozone at algorithm.com.au
Fri Feb 27 04:41:43 EST 2004
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
>> 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
> 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'
addToFM :: Ord key => FiniteMap key elt -> key -> elt -> FiniteMap key
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
More information about the Haskell