On 1 February 2011 11:47, Ozgur Akgun wrote:

So, is there a way to declare an AbGroup instance for the types with num instances only?

No - as Henning says its then no more useful than simply a function: add :: (Num u) => a -> a -> a add = (+) 'Overarching instances' i.e. classes with one implementation are a design flaw, not a virtue [*] so this hypothetical extension isn't welcome... {-# LANGUAGE OverarchingInstances #-} [*] Of course, there might be some valid cases for things in Oleg Kiselyov's typecast style, but modelling numericals doesn't look like one of them.

On Tuesday 01 February 2011 13:45:34, Ozgur Akgun wrote:

I want to be able to write the following instance to accomplish that:

instance Data t => Term t where     termTag = show . toConstr

And if the user wants to write a more specific instance, they should be welcome to do so:

instance Term UserDT where     termTag (...) = ...

I am not very much interested in the technical details about how things currently are, I am more interested in a discussion about why (if?) this would be considered a *design flaw*?

I think the strongest reason to consider it a design flaw is the current implementation, that instance selection doesn't take contexts into account. Things being as they are, an instance A a => B a where ... just isn't very useful. If instance selection took contexts into account, such an instance might be useful, but it would still prevent users from declaring instances for both classes (without an extension which would have much the same problems as OverlappingInstances).

OK, what about this as a use case then. I want to create a type class 'Term' with only one function in it. The function returns a 'termTag' which labels the

"kind" of a value in a DSL.

class Term a where termTag :: a -> String

A user of this type-class can happily provide an instance without any other type

class requirement. However, I want those types which are instances of Data to be

an instance of Term automatically. On top of that, I don't want to stop the user

from creating a special instance for their data type.

I want to be able to write the following instance to accomplish that:

instance Data t => Term t where termTag = show . toConstr

A much more predictable option is to provide this default implementation as a function termTagData :: (Data t) => (t -> String) and let the library clients use it in their instances if the behavior is fine: instance Term MyT where termTag = termTagData

And if the user wants to write a more specific instance, they should be welcome

to do so:

instance Term UserDT where termTag (...) = ...

I am not very much interested in the technical details about how things currently are, I am more interested in a discussion about why (if?) this would be considered a design flaw?

Here's one thing to consider: Can you write a function f :: (Data a) => a -> String f x = termTag x It would seem the Data a => Term a instance justifies this function, and it will always use the default instance. Now, what happens if "f" is applied to a value of some type T which is an instance of Data, but has a custom Term instance? Brandon.

On Tue, Feb 1, 2011 at 11:47 AM, Ozgur Akgun wrote:

On 1 February 2011 11:41, John Lato wrote:

...

The important point is that this declares an AbGroup instance for every type, not just types with Num instances.

So, is there a way to declare an AbGroup instance for the types with num instances only?

Not to my knowledge. John