* I'd be happy to add the ability to separate a 'deriving' clause from its data type declaration, if we can agree syntax (see below). It's fairly easy to do; it makes the language more orthogonal; it's useful.
But in fact I think only Martin Sjögren has explicitly said that the feature would be useful.... and every feature has a cost.
when you said people had asked for this before, I assumed you didn't need further pro arguments, and I didn't want to argue against a feature that would make recursive modules in Haskell less problematic. but here are two examples from the answer I didn't send: - library providers sometimes "forget" to provide useful instances, and "remote deriving" would permit programmers and their users to work around this without waiting for the next release (examples: points were not Show-able in earlier versions of wxHaskell, instances of Data/Typable were missing for the Haskell-AST in earlier versions of ghc&libs, ..). mostly interesting because so many ghc libs these days come as binary distributions, without source. - library users sometimes need instances that library providers don't need (example: HaRe uses Programatica for its Haskell frontend, but uses Strafunski instead of Programatica's built-in generic programming support; for that, we needed the various AST types to be instances of the Data/Typable-equivalents, but we didn't want to change all the Programatica sources involved, which kept evolving independently; DrIFT allowed us to do this, but the recent DrIFT-less support for scrap your boilerplates doesn't provide an equivalent without "remote deriving". mostly interesting to improve modularity, and to avoid changes in externally-maintained code (a form of aspects?-). I guess all DrIFT users would jump on the train if this was combined with user-definable deriving.
deriving( Typeable (T a) ) -- (B) Re-use 'deriving' keyword
avoiding new keywords seems preferable, but don't you need something to attach this to? perhaps the import statement (if you don't define or import it, you can't derive anything)? import Language.Haskell deriving (Typable HsExp, ..)
The trouble with (B) is that the thing inside the parens is different in this situation than in a data type declaration.
depending on syntax, one might also be able to write things that are currently not possible: module M where .. class Odd m b where .. data T a b c = .. import M deriving (Odd (T a Int) Zero,Odd (T Bool b) (Succ Zero)) without support for user-defined derive, the whole idea is a lot less interesting, though Data/Typable and Read/Show probably account for two major application areas. still, will non-variable parameters be permitted, and do we know what that means? cheers, claus