Deriving clauses for EmptyDataDecls [was: request for reviews for my first patch -- ticket 7401]

Daniel Wagner wagnerdm at
Wed Aug 14 14:36:24 CEST 2013

This is only tangentially related, but I would like to point out another 

Retroactively changing the meaning of extensions is _very_ annoying for 
library writers. cabal makes it easy to demand particular extensions 
(and make the build fail very early with a meaningful error message when 
the extension isn't available), but doesn't really provide a good way 
for a library to say "I want EmptyDataDecls, but if it's GHC, I also 
demand that it be GHC 7.8 or later because that's when the meaning of 
EmptyDataDecls changed".


On 2013-08-14 01:16, Austin Seipp wrote:
> On Mon, Aug 12, 2013 at 9:33 AM, Richard Eisenberg <eir at> 
> wrote:
>> 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.
> You're right, sorry about that. I suppose we can let someone else
> weigh in on this note.
>> 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).
> Hmmm, I'm sort of ambivalent at this point.
> Looking at the user manual[1], the relevant point for
> -XStandaloneDeriving is that "Unlike a deriving declaration attached
> to a data declaration, GHC does not restrict the form of the data
> type..."
> At the same time, from a user POV, I'd think it's reasonably annoying 
> to reject:
> data Foo deriving (Eq, Show, Ord)
> in favor of:
> data Foo
> deriving instance Eq
> deriving instance Show
> deriving instance Ord
> with an extra extension - and if you happen to mention a type
> variable, then it gets even longer since the context isn't inferred.
> Also, given that EmptyDataDecls in its current form is now standard in
> H2010, but StandaloneDeriving is not, this makes for longer code for
> people who do want to be standards compliant to write the trivial
> instance. And as a user of H2010, I'd see an empty data type as "a
> data type" - and not an extension. So I might expect deriving to work
> consistently with it, like with any other H2010 data type.
> This, I suppose, is what I was alluding to when I talked about
> 'inconsistency' earlier. Although, then it is a question of the
> standard itself! And then maybe it should be under an extra flag.
> I think there are legitimate points on all sides here. But, I think
> this is pretty squarely a 'user interface problem'. It's easy for us
> no matter what. So, I have CC'd glasgow-haskell-users - I think
> there's room for voices on this note, and I'd really appreciate users
> and developers weighing in.
> [1] 
>> Richard
>> On Aug 12, 2013, at 12:55 AM, Austin Seipp wrote:
>>> On Sun, Aug 11, 2013 at 10:00 PM, Richard Eisenberg 
>>> <eir at> 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

More information about the Glasgow-haskell-users mailing list