It is almost certainly the case that the implementation of these functions should not be the constant return True function.

Yeah, I just checked that and looks like GHC generates `error $ Void ==` ==================== Derived instances ==================== Derived instances: instance GHC.Classes.Eq Main.D where GHC.Classes.== = GHC.Err.error "Void ==" GHC.Classes./= a_aok b_aol = GHC.Classes.not ((GHC.Classes.==) a_aok b_aol) But I can't find code generation part of standalone deriving, any ideas on where is this generation part? --- Ömer Sinan Ağacan http://osa1.net

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

According to the Haskell 2010 report (http://www.haskell.org/onlinereport/haskell2010/haskellch11.html#x18-1820001...), 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 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

My proposal below doesn't really give different behavior for EmptyDataDecls in the two scenarios… the available constructs are the same under either H98 or H2010. It's just that the "distance" from the spec is different. Personally, I'm loathe to stray from a well-defined note in a standard for this. I see my proposal below as a feasible solution to #7401, but I would actually favor not implementing any change here, because the workaround -- using standalone deriving -- is so easy and doesn't seem to have any real drawbacks (e.g. performance). Richard On Aug 12, 2013, at 12:55 AM, Austin Seipp wrote:

On Sun, Aug 11, 2013 at 10:00 PM, Richard Eisenberg wrote:

...

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

IMHO, I'd find this inconsistency in extension behavior much more annoying than just going against the standard on this note. But that's just my 0.02c.

-- Regards, Austin - PGP: 4096R/0x91384671