Hello Simon, Friday, October 6, 2006, 11:41:21 AM, you wrote:

| declarations. The basic reason for maintaining a syntactic | distinction between instance declarations and deriving declarations | is to make the programmer aware of the restrictions of the deriving | mechanism.

unfortunately i don't see this whole message. but i disagree with this statement - imho, using several different mechanisms for deriving built-in classes, defining default instances, automatic generation of instances by TH, generic class definitions and automatic deriving for newtypes just confuse programmers and force to change code when one mechanism is replaced with another (say, when Typeable becomes built-in class instead of TH-generated one). so, i propose to leave only two forms of automatic instance definitions: - bundled with type definition: 'data ... deriving' clause - decoupled from type definition: 'instance Class Type' clause both forms should be allowed to be used with any class that may be automatically derived: 1) built-in classes Eq, Ord... 2) any class derived for newtype 3) class that has default definitions for all its methods: class (Enum a) => SuperEnum a where fromSuperEnum :: a -> Integer fromSuperEnum = toInteger . fromEnum 4) class that was defined using generics (currently GHC-only but i hope that future Haskell standards will support some form of Generic Haskell): class Generic a where f :: a -> a f (x :+: y) = ... f (x :*: y) = ... 5) i propose to extend GHC to allow TH generate default instance declarations. when one tries to derive XXX class, compiler should look up derivingXXX TH function and if it is defined, use this function to derive instance. so, the following: data A = B | C deriving(Binary) should be translated into data A = B | C $(derivingBinary 'A) Haskell is known as polymorphic language, but not generic one. It still lacks simple and powerful mechanism to generate class instances. Why i can't solve this problem completely, i hope that proposed extension may build some bridge to generic Haskell future, allowing at least GHC users to imagine that they work with compiler supporting user-controlled deriving mechanism imagine, for example, that you wrote serialization library with a Binary class. in first version, you have defined default Binary instance using generic classes: class Binary a where put (x :+: y) = ... put (x :*: y) = ... in the next version you have developed much more complex but efficient TH-based instance generation code: derivingBinary t = [| .... |] in third version, GHC comes with built-in Binary class support. and in the fourth version GHC includes Generic Haskell support so you can define default instance using GH. but independent of all these internal changes your clients continue to use the same deriving mechanism: data A = B | C deriving(Binary) is it not beautiful? :) | b) For deriving declarations, the compiler figures out the | constraints, whereas the programmer writes them for instance | declarations. it's real problem. in light of this i propose to extend 'deriving' mechanism so that it can derive in all the above-mentioned ways. plus, as Simon suggests, make the stand-alone 'deriving' clause the same syntax as 'instance' without constraints: data A = B | C deriving(Binary) data T a = T a deriving Binary (T a) where Binary deriving mechanism should by itself generate/check all necessary constraints -- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com