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