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

[Daniel Wagner]

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 <eir at cis.upenn.edu> 
> 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 
>>> <eir at cis.upenn.edu> 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
>>