>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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe