Re: [ghc-steering-committee] Please review: deriving for empty, Shepherd: Iavor Diatchki

I don't have a strong opinion about the pragma issue---to me this kind of divergence from Haskell 2010 is not important, as I really don't see what could possibly go wrong if you were to accidentally accept a program with a deriving clause on an empty data declaration. If another language pragma would be useful to someone though, I certainly don't mind. More generally, though, I have a feeling that perhaps we should consolidate the language pragmas a little, rather than adding more overlapping ones, especially with pragmas like `EmptyDataDecls`, which are essentially obsolete, given that the feature is in Haskell 2010, and there doesn't seem to be a particularly compelling reason to disable it. -Iavor On Mon, Aug 14, 2017 at 5:13 PM Manuel M T Chakravarty wrote:

I agree with Richard on both counts. It is unfortunate to have to introduce a new language extension, but it seems the right thing to do here.

Manuel

Richard Eisenberg :

I agree that we should accept the proposal, but there is a small snag: this proposal deviates from the Haskell 2010 Report, which (to me) clearly disallows `deriving` for empty datatypes. The proposal does not introduce a new language extension to control the new behavior, instead piggybacking on EmptyDataDecls. The only problem is that EmptyDataDecls is part of Haskell2010. Thus, this proposal marks yet one more way that GHC -XHaskell2010 will deviate from the Report.

So, I'm unequivocally in support of this proposal if we have a new -XEmptyDataDeriving (or some such), and equivocally in support of the proposal without a new extension.

Richard

On Aug 14, 2017, at 2:21 PM, Iavor Diatchki wrote:

Hello all,

I just read through this proposal, and in my mind it proposes two things:

1. Make the `deriving` syntax more consistent. Currently GHC disallows most, but not all, deriving clauses on empty declarations, but it will happily derive the instances using a stand-alone deriving declarations. The proposal suggests to simply allow `deriving` clauses on empty `data` declarations, and I agree.

2. Make the derived code for empty data declarations a bit more consistent. This is my summary of the proposed changes:

2.1. Eta-expand the generated code, so that if we are going the produce "bottom", we do so at the correct type (e.g. `showsPrec p x = ...` instead of `showsPrec = error ...`) To me this seems quite reasonable, and is what I'd expect.

2.2. When there is no meaningful result, use empty-case on the datatype, rather than `error` I think that this is a clear win, as it does not pollute the errors: the only value of a void type would be some sort of an error, and if we generate a definition using `error`, we give GHC a choice, where it could report either the original one, or the new one. I think it is better to avoid this and just keep the original one, as it is likely to be more useful.

2.3. Be "maximally defined" when there is a reasonable default value (e.g., return `True` for `Eq`, or `mempty` for `Foldable`). I am most ambivalent on this one is it seems weird to compare "bottom" values and get `True` as a result. However, according to the comments on the proposal, this sort of thing can be occasionally useful for some strange recursive definitions. I have not encountered such examples, but I don't really think it matters very much, and perhaps it'd be useful to someone.

2.4 Other misc. fixes: apparently the derived instance for `Read` on an empty type currently requires `parens`, which seems odd. The proposal suggests that the parsing should just fail, which to me makes sense.

Based on that, I'd suggest that we accept the proposal. What do other folks think?

-Iavor

On Sun, Aug 13, 2017 at 6:32 AM Joachim Breitner wrote:

...

Dear Committee,

this is your secretary speaking:

https://github.com/ghc-proposals/ghc-proposals/pull/63 was brought before the committee, by Ryan Scott.

I propose Iavor Diachki as the Shepherd.

Iavor, please reach consensus as described in https://github.com/ghc-proposals/ghc-proposals#committee-process

I suggest you make a recommendation about the decision, maybe point out debatable points, and assume that anyone who stays quiet agrees with you. -- Joachim “nomeata” Breitner mail@joachim-breitner.de https://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee