[Haskell-cafe] The difficulty of designing a sequence class

[John Meacham]

On Tue, Aug 01, 2006 at 02:56:21AM +0100, Brian Hulley wrote:
> Now the problem is that person C may come along and notice that there is a 
> useful abstraction to be made by inheriting both from ClassA and ClassB. 
> But both of these define "foo" and there is no mechanism in the language to 
> resolve this.

This is not true at all. every name in haskell can be uniquely
specified.

>     module ClassA where
>     class ClassA a where
>         foo :: a -> Int
> 
>     module ClassB where
>     class classB a where
>         foo :: a -> String
> 
>     import ClassA
>     import ClassB
>     class (ClassA a, ClassB a) => ClassC a where
>         bar :: a -> (Int, String)
>         bar x = (ClassA.foo x, ClassB.foo x)


> I'm also wondering if it would be a good idea to be able to declare some 
> class methods as final, so they don't clutter up the dictionary at runtime, 
> and so that we could end the dubious practice of declaring some functions 
> which are conceptually part of a class as top level functions outside the 
> class just to save space/time in the dictionary and therefore needing the 
> physical module to create the conceptual grouping instead of using the 
> language level grouping provided by the class name.


I think a fundamental thing you are missing is that Haskell classes are
not like C# or Java or other OO classes. Not because of implementation,
but rather they are actually fundamentally different things.

The reasons people don't place certain functions in classes has nothing
to do with the size of class dicionaries. Heck, jhc doesn't even use
dictionaries at all, there is no cost for adding methods to a class.
People place them in top level functions because it makes more sense. of
course, sometimes it is gotten wrong, and something would have been
better off as a class method, but in general there are different
concerns when dealing with haskell classes than OO classes.

An OO class could be considered equivalent to a triplet of a Haskell
data type, a Haskell existential with a class constraint, and a class
with the resriction the class type can _only_ appear as the first
argument to each method. In haskell all of these things are separate
independent tools and are much more general and powerful than the
limited and conjoined form that OO programming provides.

> Anyway these are probably more long term ideas but I mentioned them now 
> just to hopefully start the ball rolling (the above should not be taken as 
> a criticism of Haskell, I'm just saying that at some point we need all the 
> normal mechanisms that everyone else (Java, C#) takes for granted because 
> there's no point waiting till we encounter the same well-known software 
> engineering problems that already have well established good solutions).

It is best to think of haskell primitives as something completely new,
they reuse some naming conventions from OO programming, but that doesn't
mean they suffer from the same limitations. It took me a few trys to
wrap my brain around it. I liken learning haskell to tipping over a
vending machine. you can't just push it, you gotta rock it back and
forth a few times building up momentum until bam! suddenly the flash of
insight hits and it all makes sense.

        John

-- 
John Meacham - ⑆repetae.net⑆john⑈