[Haskell] recursive deriving

Lennart Augustsson lennart at augustsson.net
Wed Nov 21 03:17:31 EST 2007


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 <duncan.coutts at 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 at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20071121/8034716e/attachment.htm


More information about the Glasgow-haskell-users mailing list