Re: [Haskell] recursive deriving
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
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
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).
On Nov 21, 2007 12:59 AM, 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?
Duncan _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
participants (3)
-
Don Stewart -
Duncan Coutts -
Lennart Augustsson