[Haskell-cafe] Re: [Haskell] recursive deriving

[Don Stewart]

duncan.coutts:
> On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote:
> > When you want automated deriving of show/read etc., you need all the 
> > components of your type also to be instances of show/read but you won't 
> > want to *require* them to be automatically generated verions.
> > 
> > Standalone deriving does the wrong thing here.  Standalone deriving 
> > should not cause an overlapping instance error if someone derives an 
> > instance manually.  Instead, the manually derived instance should be 
> > treated as more specific and win out.
> > 
> > The other part of this problem is that you can't do automatic recursive 
> > deriving and this results in a ridiculous amount of boilerplate.  I know 
> > some people have a theory that they want to avoid accidentally creating 
> > instances for things that shouldn't have them, but the solution to that 
> > is probably to add some declaration for types that prohibits automatic 
> > deriving for those types.  The 99% case is that automatic deriving is ok.
> > 
> > Proposed syntax:
> > 
> >    derive instance Show T recursively
> >    data T = T no-deriving (Ord,Eq)
> 
> I would expect that if the data constructor for T is not exported then
> standalone deriving should not work. However this appears not to be the
> case which breaks module abstraction.
> 
> Foo.hs:
> module Foo ( T, t ) where
> data T = T
> t = T
> 
> Bar.hs:
> import Foo
> deriving instance Eq T
> 
> $ ghci Bar.hs -XStandaloneDeriving
> [1 of 2] Compiling Bar              ( Bar.hs, interpreted )
> [2 of 2] Compiling Main             ( Baz.hs, interpreted )
> Ok, modules loaded: Bar, Main.
> *Main> t == t
> True
> 
> You could write that Eq instance by hand since they do not have access
> to the T constructor, then StandaloneDeriving should not be able to so
> either. I think it's a design flaw in standalone deriving.
> 
> Does anyone else agree? Should we file a bug report?

Yes, this seems wrong.

-- Don