On Fri, Apr 25, 2008 at 05:37:17PM +0100, Simon Peyton-Jones wrote:
John
OK here's a question about class alisas. You propose:
class Foo a where foo :: a -> [a] foo x = [] class Bar a where bar :: a -> a bar x = [x]
class alias FooBar a = (Foo a, Bar a) where foobar :: a -> a foobar x = x
foo x = bar x
I have a few minor questions about this that'd be worth clarifying on your main page (a) I assume you can add a method 'foobar' not declared in either Foo or Bar. Your very first example has this. But it's contradicted later when you say that "One can declare an instance of Num either by giving separate instances for Eq, Additive, Multiplicative"
No, I didn't mean to imply that. as you noted, that would mean that an alias would not be a simple preprocessing. what you can do is create a real class FooBar which has both foo and bar as superclasses, then create an alias for all three so you can create a single instance to define all three. It might be possible to add this though and have it automatically create an appropriate class and a class alias. but I think that might muddy the intent of class aliases if not all can be described as simple aliases for other existing classes. So we can reserve that as a possible future extension. it is easy enough to manually create the 'foobar' containing class in any case and if you don't export it from your module, you get the equivalent effect.
(b) And I assume that you don't need to repeat the type signatures for 'foo' and 'bar'.
Yup, no need to repeat type signatures.
(c) I think you intend that you can override the default methods for foo and bar; and I have done so for method 'foo'.
Yes. being able to override default instances is a key part, otherwise you wouldn't be able to, for instance, create appropriate 'Num' compatible methods from your advanced 'NewNum' class alias. But you are not forced to do so.
Question: how does the above differ from this?
class (Foo a, Bar a) => FooBarSC a where foobar :: a -> a
Here Foo, Bar are simply superclasses. From the point of view of a type signature there *no* difference:
f :: (FooBarSC a) => ...
gives access to all the methods of Foo and Bar. So what's the difference?
Answer (I believe): when you give an instance of FooBar you give implementations for all methods of Foo, Bar, and FooBar.
Yes, it is because you cannot declare an instance of FooBarSC and have it also create the ones for Foo and Bar, and because you can't create new default instances for 'foo' and 'bar' that refer to 'foobar'.
So the obvious question is: do we really need a new construct? Why not just use FooBarSC? Then we'd have to allow you to give implementations for superclass methods too: instance FooBarSC Int where foobar = ... foo = ... bar = ...
I think I believe (like you) that this is a bad idea. The main reason is that it's a totally unclear whether, given a FooBarSC Int instance declaration, should there be an instance for (Foo Int), always, never, or optionally?
Yes. and it breaks one of the major haskell properties I am not willing to give up, That when you add an import to your module (or any module you depend on), your program will either fail to compile or have the _exact_ same meaning.
However, I think you might want to articulate the reasons carefully, because we have two features that are really extremely close.
Yes, I think the above might help with the lattice case, where you have a strict hierarchy of classes and the superclass tree mirrors your class aliases, but this may not be the case in general. in particular, we don't want to necessarily redo the numeric hierarchy as a strict generalization or splitting up of the current prelude numerical hierarchy, and the superclass method gets a little hairy when you want to do things like that and don't want to end up with every method in its own class.
To put it another way, you could imagine re-expressing your proposal like this:
class (Eq a) && (Additive a, Multiplicative a) => Num a
meaning this: when you give an instance for (FooBar T) you
* MUST give implementations for the methods of Addititive and Applicative
* MUST NOT give implementations for methods of Eq; rather the Eq T instance must be in scope.
This is, I believe, what you mean by class alias Num a = Eq a => (Additive a, Multiplicative a)
Now I'm not necessarily suggesting this as concrete syntax. But my point is that you're really asking for small modification of the existing superclass mechanism, that divides the superclasses into two groups, the "flat" ones (like Additive and Multiplicative) and the "nested" ones (like Eq). Is that right? If so, a syntax that is more suggestive of the current superclass declaration looks better to me.
Hmm.. I consider class aliases orthogonal and complementary to superclasses, rather than a generalization of them. I do not think that what one wants out of a superclass hierarchy and a class alias collection (note, I don't say hierarchy) will be the same and having them mirror each other will create a tension between the two in how one designs their code.
This close relationship also suggests strongly that the answer to (a) above should be 'yes', since you can certainly add methods to a class with superclasses.
Yeah, I disagree here, mainly because I don't want to conflate superclasses with class aliases. I feel they have different uses, even though they can sometimes achieve the same thing. Part of this is my 'sather' heritige, sather was a pretty cool fully type safe (in the stronger FP sense moreso than the java sense) object oriented language that was somewhat based on eiffel, but with the advantage of being designed by people with a stronger grasp of type theory than the eiffel designer. One of its major innovations was a separation of code reuse from class inheritance. In traditional object oriented languages, inheritance is both a method of code reuse (by defining non abstract superclasses with virtual methods that can be overridden), and of expressing a strong relationship between the types. However the sather designers realized these two things were not necessarily related, their solution was to define superclasses as _always_ being abstract, and having a different mechanism for code reuse. It was quite nice. enough so that I started (not as elegantly) using that approach in other OO languages I was using. Had I not discovered Haskell, I would likely still be the sather language maintainer :) I believe that class aliases define a method of code (instance method in particular) reuse. When you define your 'HaskellPrimePrelude' instances, you want the code to automatically and transparently be used to define 'Haskell98Prelude' instances, likewise, when you define 'Haskell98Prelude' instances, you want the code to automatically and transparently define 'HaskellPrimePrelude' instances. However, there is no clear superclass relationship between the two and being forced to introduce an artificial one would obfuscate things I think. John -- John Meacham - ⑆repetae.net⑆john⑈