<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">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.<div class=""><br class=""></div><div class="">Manuel<br class=""><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">Richard Eisenberg <<a href="mailto:rae@cs.brynmawr.edu" class="">rae@cs.brynmawr.edu</a>>:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">Richard</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Aug 14, 2017, at 2:21 PM, Iavor Diatchki <<a href="mailto:iavor.diatchki@gmail.com" class="">iavor.diatchki@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">Hello all,<div class=""><br class=""></div><div class="">I just read through this proposal, and in my mind it proposes two things:</div><div class=""> </div><div class=""> 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.</div><div class=""><br class=""></div><div class=""> 2. Make the derived code for empty data declarations a bit more consistent. This is my summary of the proposed changes:</div><div class=""><br class=""></div><div class=""> 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 ...`)</div><div class=""> To me this seems quite reasonable, and is what I'd expect.</div><div class=""><br class=""></div><div class=""> 2.2. When there is no meaningful result, use empty-case on the datatype, rather than `error`</div><div class=""> 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.</div><div class=""><br class=""></div><div class=""> 2.3. Be "maximally defined" when there is a reasonable default value (e.g., return `True` for `Eq`, or `mempty` for `Foldable`).</div><div class=""> 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.</div><div class=""><br class=""></div><div class=""> 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.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">Based on that, I'd suggest that we accept the proposal. What do other folks think?</div><div class=""><br class=""></div><div class="">-Iavor<br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Aug 13, 2017 at 6:32 AM Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" class="">mail@joachim-breitner.de</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Committee,<br class="">
<br class="">
this is your secretary speaking:<br class="">
<br class="">
<a href="https://github.com/ghc-proposals/ghc-proposals/pull/63" rel="noreferrer" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals/pull/63</a><br class="">
was brought before the committee, by Ryan Scott.<br class="">
<br class="">
I propose Iavor Diachki as the Shepherd.<br class="">
<br class="">
Iavor, please reach consensus as described in<br class="">
<a href="https://github.com/ghc-proposals/ghc-proposals#committee-process" rel="noreferrer" target="_blank" class="">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br class="">
<br class="">
I suggest you make a recommendation about the decision, maybe point out<br class="">
debatable points, and assume that anyone who stays quiet agrees with<br class="">
you.<br class="">
--<br class="">
Joachim “nomeata” Breitner<br class="">
<a href="mailto:mail@joachim-breitner.de" target="_blank" class="">mail@joachim-breitner.de</a><br class="">
<a href="https://www.joachim-breitner.de/" rel="noreferrer" target="_blank" class="">https://www.joachim-breitner.de/</a><br class="">
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class=""><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class=""></div></blockquote></div><br class=""></div>_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></div></div></body></html>