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 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 mailto:mail@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@joachim-breitner.de mailto:mail@joachim-breitner.de https://www.joachim-breitner.de/ https://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

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 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 :

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 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 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@joachim-breitner.de https://www.joachim-breitner.de/ _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Aug 16, 2017, at 6:11 PM, Joachim Breitner wrote:

that touches on a more fundamental question: How strict do we want to be with the “every divergence from the standard requires an extension” rule.

I think this is a great question to ask, but I would want more community feedback on this point than just us in the committee. My stance is that, absent this discussion, we should stay quite strict on that rule. (In the discussion, I would argue that adherence to the standard is less necessary.) Richard

+1 on the proposal, with an extension flag. I think we should continue to be strict about language extension flags. Extension flags allow the programmer to signal very clearly which features they're using, which allows us to write code that will be correctly rejected with a useful error message both by older versions of GHC and by hypothetical other compilers that don't support the extension. If we start to relax the policy of having extension flags, then it's hard to know where to stop. Yes we have already diverged from Haskell2010, but so far there was a compelling reason to do so in each case: e.g. we had no good way to support both versions of the Monad hierarchy, and for NondecreasingIndentation I think we had been accepting the extended syntax (without the flag) already in previous versions. Cheers Simon On 17 August 2017 at 17:47, Christopher Allen wrote:

I'd tend to agree that we should strictly respect the standard, eschewing "benign" augmentations. Part of my discomfort with this is my experience talking to programmers who hand-waved effects in general as benign. Without a formal definition of benign such as exists in the Semantic Versioning standard I'd just as soon not add something like this without putting it behind an extension.

I'm a soft +1 on the proposal as an extension.

On Thu, Aug 17, 2017 at 10:05 AM, Richard Eisenberg wrote:

...

...

On Aug 16, 2017, at 6:11 PM, Joachim Breitner

wrote:

...

...

that touches on a more fundamental question: How strict do we want to be with the “every divergence from the standard requires an extension” rule.

I think this is a great question to ask, but I would want more community feedback on this point than just us in the committee. My stance is that, absent this discussion, we should stay quite strict on that rule.

(In the discussion, I would argue that adherence to the standard is less necessary.)

Richard _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Chris Allen Currently working on http://haskellbook.com _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee