Deriving clauses for EmptyDataDecls [was: request for reviews for my first patch -- ticket 7401]
wagnerdm at seas.upenn.edu
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
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>
>> 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, 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
> 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.
>> 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
>>>> 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
>>>> This proposal brings the annoyance that H2010 no longer implies
>>> IMHO, I'd find this inconsistency in extension behavior much more
>>> annoying than just going against the standard on this note. But
>>> just my 0.02c.
>>> Austin - PGP: 4096R/0x91384671
More information about the Glasgow-haskell-users