This seems very, very wrong. The missing instance(s) might be left out because of some good reason (e.g. if you have implemented sets with list and not provided Ord).<br><br><div class="gmail_quote">On Nov 21, 2007 12:59 AM, Duncan Coutts <
<a href="mailto:duncan.coutts@worc.ox.ac.uk">duncan.coutts@worc.ox.ac.uk</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d">
On Tue, 2007-11-20 at 19:18 -0500, Alex Jacobson wrote:<br>> When you want automated deriving of show/read etc., you need all the<br>> components of your type also to be instances of show/read but you won't<br>> want to *require* them to be automatically generated verions.
<br>><br>> Standalone deriving does the wrong thing here. Standalone deriving<br>> should not cause an overlapping instance error if someone derives an<br>> instance manually. Instead, the manually derived instance should be
<br>> treated as more specific and win out.<br>><br>> The other part of this problem is that you can't do automatic recursive<br>> deriving and this results in a ridiculous amount of boilerplate. I know<br>
> some people have a theory that they want to avoid accidentally creating<br>> instances for things that shouldn't have them, but the solution to that<br>> is probably to add some declaration for types that prohibits automatic
<br>> deriving for those types. The 99% case is that automatic deriving is ok.<br>><br>> Proposed syntax:<br>><br>> derive instance Show T recursively<br>> data T = T no-deriving (Ord,Eq)<br><br></div>
I would expect that if the data constructor for T is not exported then<br>standalone deriving should not work. However this appears not to be the<br>case which breaks module abstraction.<br><br>Foo.hs:<br>module Foo ( T, t ) where
<br>data T = T<br>t = T<br><br>Bar.hs:<br>import Foo<br>deriving instance Eq T<br><br>$ ghci Bar.hs -XStandaloneDeriving<br>[1 of 2] Compiling Bar ( Bar.hs, interpreted )<br>[2 of 2] Compiling Main (
Baz.hs, interpreted )<br>Ok, modules loaded: Bar, Main.<br>*Main> t == t<br>True<br><br>You could write that Eq instance by hand since they do not have access<br>to the T constructor, then StandaloneDeriving should not be able to so
<br>either. I think it's a design flaw in standalone deriving.<br><br>Does anyone else agree? Should we file a bug report?<br><br>Duncan<br>_______________________________________________<br>Glasgow-haskell-users mailing list
<br><a href="mailto:Glasgow-haskell-users@haskell.org">Glasgow-haskell-users@haskell.org</a><br><a href="http://www.haskell.org/mailman/listinfo/glasgow-haskell-users" target="_blank">http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
</a><br></blockquote></div><br>