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

[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 <chak at justtesting.org>
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 <rae at cs.brynmawr.edu>:
>
>
> 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>
> 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
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> 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/20170816/172f54ed/attachment.html>