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

[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 <iavor.diatchki at gmail.com> 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 <mail at joachim-breitner.de <mailto:mail at joachim-breitner.de>> wrote:
> Dear Committee,
> 
> this is your secretary speaking:
> 
> https://github.com/ghc-proposals/ghc-proposals/pull/63 <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 <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 at joachim-breitner.de <mailto:mail at joachim-breitner.de>
>   https://www.joachim-breitner.de/ <https://www.joachim-breitner.de/>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20170814/88f33178/attachment.html>