This is only tangentially related, but I would like to point out another consideration: 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". ~d On 2013-08-14 01:16, Austin Seipp wrote:

On Mon, Aug 12, 2013 at 9:33 AM, Richard Eisenberg 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] http://www.haskell.org/ghc/docs/7.6.3/html/users_guide/deriving.html

...

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