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

[Brian Hulley]

John Meacham wrote:
> 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)

Hi John -
Thanks for pointing this out. The only thing that I find slightly uneasy 
about it is that you have to keep the module names and class names in sync 
so that "ClassA.foo" which means "the value foo exposed by the module 
ClassA" is in truth the same as "the foo method of class ClassA". The 
language doesn't enforce this correspondence (indeed perhaps such a 
correspondence would be undesirable but it's difficult to get used to this 
need to keep different entities in sync instead of just being able to name 
the concept once in one place).

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

I think the transition from OOP to Haskell is difficult because although OOP 
is less powerful for the reasons you've mentioned, many of the decisions you 
have to make when writing Haskell code just don't exist in OOP eg in C# 
there are no modules to worry about, every class belongs to a file with the 
same name, you don't need to decide where to put the object argument and 
there are no top level functions or values.

In contrast, in Haskell you have to juggle class declarations, instance 
declarations, types, values which may or may not be part of a class, and 
decide which combinations of the above should go into which modules and what 
the names of the modules should be and manually remember to keep some module 
names and class names (or type names eg Data.Set and data Set a = ...) in 
sync.

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

Hopefully my neural pathways will reconnect themselves soon to take 
advantage of all this new power!!! :-)

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

Great image! We need a film or video of "a day in the life of Haskell" with 
these kind of things in it eg camera cutting from scene of vending machine 
satori to animated folds rippling through space gathering structure like a 
new planet forming, then another cut to a silent robed figure casting 
objects from a sack into a bottomless pit... :-)

Best regards, Brian.

-- 
Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.

http://www.metamilk.com