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

[Edward A Kmett]

StandaloneDeriving always struck me as a really heavyweight way to write those instances. EmptyDataDecls in many ways should have been in all along while StandaloneDeriving is a rather peculiar ghc'ism.

I'm personally in favor of just making EmptyDataDecls "work better" here.

-Edward

On Aug 14, 2013, at 1:16 AM, Austin Seipp <aseipp at pobox.com> 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
> 
> 
> 
> -- 
> Regards,
> Austin - PGP: 4096R/0x91384671
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users