I actually think a warning/deprecation period should be down in this case. It doesn’t break code right now. It is not critical for this to be fixed immediately (nothing significantly averse will happen to someone accidentally using this). I’m willing to put some of IOGs resources at helping with implementing the deprecation warnings; leading by example, hoping this will inspire others to do the same in the future. Best, Moritz On Mon, 25 Sep 2023 at 7:49 PM, Eric Seidel wrote:

I agree with Moritz that a GHC Proposal is not necessary. Proposals should be used for changes in *intended* user-facing behavior, this is just a routine bugfix.

I also agree that a warning/deprecation period would be good, but I wouldn't spend overly on it. This sounds like a very easy issue to work around, just enable the extension explicitly. (Or would that have potential second-order consequences?)

On Mon, Sep 25, 2023, at 05:03, Simon Peyton Jones wrote:

...

Dear GHC SC

You may or may not have been following GHC ticket #22141 https://gitlab.haskell.org/ghc/ghc/-/issues/22141, and Ryan's merge request !11314 https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314.

The story is this: • There is a bug in GHC that allows programs to use DataKinds without the -XDataKinds extension. • The MR fixes the bug. • But of course that will mean that some programs that previously compiled (exploiting the bug) will now fail to compile (correctly). It seems like an example of our (GR2) discussion, but with a very different flavour than the (3+4=8) example.

Personally I think we should do it -- with a deprecation cycle saying "You need DataKinds for this program, and you don't have it on, but you will need it in the next release". I don't want us to grandfather bugs into GHC indefinitely -- although you could argue that the status quo does little harm, I suppose.

Any views? We will have some idea of the impact on head.hackage shortly.

*And specifically: do you want a GHC proposal for this change?*

Simon _______________________________________________ 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

Indeed a bugfix with deprecation cycle seems entirely right.

On 25 Sep 2023, at 14:30, Richard Eisenberg wrote:

Yes, let's fix the bug with a deprecation cycle.

...

On Sep 25, 2023, at 8:43 AM, Moritz Angermann mailto:moritz.angermann@gmail.com> wrote:

I actually think a warning/deprecation period should be down in this case. It doesn’t break code right now. It is not critical for this to be fixed immediately (nothing significantly averse will happen to someone accidentally using this).

I’m willing to put some of IOGs resources at helping with implementing the deprecation warnings; leading by example, hoping this will inspire others to do the same in the future.

Best, Moritz

On Mon, 25 Sep 2023 at 7:49 PM, Eric Seidel mailto:eric@seidel.io> wrote:

...

I agree with Moritz that a GHC Proposal is not necessary. Proposals should be used for changes in *intended* user-facing behavior, this is just a routine bugfix.

I also agree that a warning/deprecation period would be good, but I wouldn't spend overly on it. This sounds like a very easy issue to work around, just enable the extension explicitly. (Or would that have potential second-order consequences?)

On Mon, Sep 25, 2023, at 05:03, Simon Peyton Jones wrote:

...

Dear GHC SC

You may or may not have been following GHC ticket #22141 https://gitlab.haskell.org/ghc/ghc/-/issues/22141, and Ryan's merge request !11314 https://gitlab.haskell.org/ghc/ghc/-/merge_requests/11314.

The story is this: • There is a bug in GHC that allows programs to use DataKinds without the -XDataKinds extension. • The MR fixes the bug. • But of course that will mean that some programs that previously compiled (exploiting the bug) will now fail to compile (correctly). It seems like an example of our (GR2) discussion, but with a very different flavour than the (3+4=8) example.

Personally I think we should do it -- with a deprecation cycle saying "You need DataKinds for this program, and you don't have it on, but you will need it in the next release". I don't want us to grandfather bugs into GHC indefinitely -- although you could argue that the status quo does little harm, I suppose.

Any views? We will have some idea of the impact on head.hackage shortly.

*And specifically: do you want a GHC proposal for this change?*

Simon _______________________________________________ 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

---

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

---

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

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