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

[ozone at algorithm.com.au]

On 27/02/2004, at 9:51 AM, David Bergman wrote:

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

Yes, what I'm referring to is essentially overloading.  I called it 
"object-oriented polymorphism" because that's typically what OO people 
call such a thing :).  (I should know better to use OO terminology on a 
Haskell list; won't happen again ...).  However, it's form of 
overloading that Haskell cannot currently handle  well with type 
classes -- Oleg's post proves that you can do it, of course, but that's 
a (very good) hack rather than a long-term solution.

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

It's a bit like Koenig lookup in that it has the same effect, although 
it's probably easier for the compiler to infer the namespace wanted, 
since we write "expr.function ..." rather than "function expression 
...".  Writing "function expression ..." would work too, but then it 
looks like a standard function call rather than a function call 
associated with a particular type, and I think that causes more 
confusion.  Long-time Haskell users understand that writing "foo.f" 
means "use f in namespace foo"; changing around the language semantics 
to mean that "f foo" now means "use f in namespace foo" would make lots 
of people rather unhappy :).

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

I'm not sure what you mean by "intranamespcial parameter type lookup" 
-- can you explain?

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

I (think I) understand the difference between dynamic binding vs 
overloading: here, all I'm after is trying to use the type system to 
give us a very simple form of overloading (e.g. based on the first 
argument to a function), that gives us the same effect as a per-type 
name space.


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