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

[Iavor Diatchki]

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>
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 at joachim-breitner.de
>   https://www.joachim-breitner.de/
> _______________________________________________
> 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/cb305e6a/attachment.html>