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