On Nov 21, 2007 12:59 AM, Duncan Coutts <
duncan.coutts@worc.ox.ac.uk> wrote:
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
_______________________________________________
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users