According to the Haskell 2010 report (http://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-18200011), a datatype with no constructors cannot derive any instances.
But, instead of creating a new extension for this feature, what about just co-opting EmptyDataDecls? More concretely, I propose this: Under H98: EmptyDataDecls allows both the declaration of empty data decls and deriving instances for them. Under H2010: EmptyDataDecls allows deriving instances for empty data decls. This proposal brings the annoyance that H2010 no longer implies EmptyDataDecls. Thoughts? Richard On Aug 11, 2013, at 10:28 PM, Austin Seipp wrote: > Technically, EmptyDataDecls is part of Haskell 2010, so it is standard > these days (and H2010 is our default in GHC.) > > As far as I know, the 2010 standard doesn't address this point about > deriving for empty data decls, but I agree with your reasoning here. > It's more consistent to have it apply to all of the base classes which > are derivable. > > On Sun, Aug 11, 2013 at 9:14 PM, Richard Eisenberg <e...@cis.upenn.edu> wrote: >> Maybe it's best if Show, Ord, etc., echo the new behavior for Eq, if >> EmmptyDataDecls is specified. The reason for the check in cond_stdOK is to >> make sure that we're conforming to the Haskell standard. But, if the user >> has specified EmptyDataDecls, then we're not bound to that requirement >> anymore. So, to me, it seems reasonable that the "null data_cons" check >> should be omitted for any class if EmptyDataDecls is specified. >> >> What do others think? This would go beyond the scope of the particular >> reported bug, but it seems to make sense to me. >> >> Thanks, >> Richard >> >> On Aug 9, 2013, at 3:16 PM, Ömer Sinan Ağacan wrote: >> >>> Removing `null data_cons`(compiler/typecheck/TcDeriv.lhs 1105) check >>> for eq instance declarations fixes this, code generation part would be >>> same(changes in TcGenDeriv.hs were wrong and TcGenDeriv needs to be >>> unchanged)but I'm not sure how to remove that check only for eq >>> instance(Show, Ord, etc. sould still fail with same error message and >>> they're checked by same function, `cond_stdOK` -- line 1053). >>> >>> --- >>> Ömer Sinan Ağacan >>> http://osa1.net >>> >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs@haskell.org >>> http://www.haskell.org/mailman/listinfo/ghc-devs >>> >> >> >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs@haskell.org >> http://www.haskell.org/mailman/listinfo/ghc-devs > > > > -- > Regards, > Austin - PGP: 4096R/0x91384671 > _______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
