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

[Brian Hulley]

Brian Hulley wrote:
> David Menendez wrote:
>> Brian Hulley writes:
>>> 4) Would it be worth reconsidering the rules for top level names so
>>> that class methods could always be local to their class (ditto for
>>> value constructors and field names being local to their type
>>> constructor).
>>
>> Qualified module imports are the way to go, here. Do you really want
>> to start writing "if x Eq/== y Num/+ 1 then ... "?
>
> I'm beginning to see that qualified module imports are indeed the
> only way to go,

One reason I forgot: Suppose person A writes ClassA which uses "foo" as a 
method name, and somewhere else, person B writes ClassB which also uses 
"foo" as a method name, and both classes become widely used for several 
years.

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.

The language C#, which was designed from the outset for programming in the 
large, already had a solution in the very first release of C#, namely that 
the interface name could be used to qualify a method name in cases of 
ambiguity, so transposing this to Haskell, you'd have something like:

     class ClassA a where
         foo :: a -> Int

     class classB a where
         foo :: a -> String

     class (ClassA a, ClassB a) => ClassC a where
         bar :: a -> (Int, String)
         bar x = (ClassA#foo x, ClassB#foo x)

As I see it, Haskell, great and innovative as it is, is still stuck in 
"programming in the small" and some of the mechanisms needed for programming 
in the large are not yet available - it is as impossible to ensure that 
there will never be conflicts between names of class methods as it is to 
ensure that there will never be conflicts between module names in packages 
written by different groups of people, and languages like Java and C# solved 
these problems right at the beginning but Haskell for some reason has 
ignored the issues, only recently just starting to address the package 
module name conflict problem for example even though the language has been 
around for more than a decade.

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.

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

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