Hi, Am Dienstag, dem 21.06.2022 um 10:47 +0100 schrieb Simon Marlow:

If it's backported to 9.2, then code wanting to use it would need to have a `ghc >= 9.2.4` constraint in the `.cabal` file, which is a bit unusual. We don't normally add new language features in a patchlevel release. But this isn't a strong argument for not doing it I guess - you would need that constraint if you relied on some bug that was fixed in 9.2.4 too.

Slight digression, but does Cabal even allow specifying bounds on the compiler implementation? If you put this into the build-depends it might have that effect, but it will also depend on ghc-the-library, not what people usually do. If I need to depend on a specific version of GHC, I tend to peek at https://gitlab.haskell.org/ghc/ghc/-/wikis/commentary/libraries/version-hist... and hope that base was bumped together with it, and depend on that version of base. Is there a better way? Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Hi, Am Dienstag, dem 21.06.2022 um 11:45 +0100 schrieb Simon Marlow:

...

Slight digression, but does Cabal even allow specifying bounds on the compiler implementation? If you put this into the build-depends it might have that effect, but it will also depend on ghc-the-library, not what people usually do.

Yes, you can do this (stolen from one of my .cabal files):

    if impl(ghc >= 8.8)       buildable: True     else       buildable: False

just in case someone reads our conversation here, TIL that the using buildable is not quite correct, and should probably be if impl(ghc < 8.8) build-depends: unbuildable <0 according to Oleg in  https://github.com/haskell/mtl/issues/138#issuecomment-1369068398 Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Eric, After the exchange on Github: are you still hesitant? On Sun, Jun 26, 2022 at 3:24 PM Eric Seidel wrote:

I think this is a particularly hard fork to stomach, because -XDeepSubsumption must be enabled in *client modules* in order to gain the usability benefits. That makes it quite infectious, and puts the burden of reasoning about complications from auto-eta-expansion on users rather than library authors.

I've asked the authors on GitHub to consider an alternative where *library authors* flag modules/functions/parameters as being candidates for auto-eta-expansion instead. It seems like that may provide the same usability benefits to clients, but importantly puts the pebble in the right shoe wrt language complexity.

...

I'm never a fan of fork-like things, but as long as we're clear that -XDeepSubsumption is not recommended and will not be on by default in a future GHC20XX then I suppose it's OK.

If it's backported to 9.2, then code wanting to use it would need to have a `ghc >= 9.2.4` constraint in the `.cabal` file, which is a bit unusual. We don't normally add new language features in a patchlevel release. But this isn't a strong argument for not doing it I guess - you would need that constraint if you relied on some bug that was fixed in 9.2.4 too.

Cheers Simon

On Mon, 20 Jun 2022 at 14:56, Spiwack, Arnaud wrote:

...

Dear all,

The Deep Subsumption proposal [ https://github.com/ghc-proposals/ghc-proposals/pull/511 ] proposes a new extension, -XDeepSubsumption, which, when activated, partially reverts the changes from the Simplified Subsumption proposal.

The Simplified Subsumption breaks more programs than anticipated. Many don't see any benefit from Simplified Subsumption, just the breakage, and don't like the eta-expansion that it forces.

-XDeepSubsumption, when activated, restores deep skolemisation and co/contra-variance of the function arrow (but not deep instantiation, which doesn't affect the observed breakage). The patch already exists for it, and is about 400loc.

There are two interesting highlights for me. - It is proposed that -XDeepSubsumption is activated by default in Haskell98 and Haskell2010, but not GHC2021. -XDeepSubsumption is orthogonal to Haskell2010, as far as I can tell, but it gives a cut-off point from which the recommended behaviour (-XNoDeepSubsumption) is the default. - Even with -XDeepSubsumption, the Quick Look algorithm assumes that

...

...

The authors also have one unresolved question that I'm bringing to the

committee's attention: should `-XDeepSubsumption` be backported to GHC 9.2?

...

---

Despite the fact that this extension is decidedly fork-like, and that

it's a real possibility to see the community split around this (after all,

On Tue, Jun 21, 2022, at 05:47, Simon Marlow wrote: the function arrow is invariant. The consequences of that are difficult to anticipate, but there is no known example of a bad behaviour due to that interaction yet. the motivation for -XDeepSubsumption is a few libraries which were designed to leverage GHC's deep subsumption, and may very well stay that way in the foreseeable future). I recommend acceptance. Providing a path to backward compatibility seems to me like the right thing to do.

...

...

I also recommend backporting to GHC 9.2. It should essentially be

backward compatible, and providing an update path that doesn't go directly from 9.0 to 9.4 feels better to me.

...

_______________________________________________ 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

Thanks Eric. Arnaud, thanks for pushing on this. If the committee is ready, I'd love to get this decided, so we can land it in GHC, including back-ports to older GHCs, whose release is imminent. Simon On Thu, 30 Jun 2022 at 15:18, Eric Seidel wrote:

I'm on board with acceptance. I do think a backport to older GHC 9.x's would make sense if it's not too much work

...

Eric,

After the exchange on Github: are you still hesitant?

On Sun, Jun 26, 2022 at 3:24 PM Eric Seidel wrote:

...

I think this is a particularly hard fork to stomach, because -XDeepSubsumption must be enabled in *client modules* in order to gain the usability benefits. That makes it quite infectious, and puts the burden of reasoning about complications from auto-eta-expansion on users rather than

...

...

I've asked the authors on GitHub to consider an alternative where

*library authors* flag modules/functions/parameters as being candidates for auto-eta-expansion instead. It seems like that may provide the same usability benefits to clients, but importantly puts the pebble in the right shoe wrt language complexity.

...

On Tue, Jun 21, 2022, at 05:47, Simon Marlow wrote:

...

I'm never a fan of fork-like things, but as long as we're clear that -XDeepSubsumption is not recommended and will not be on by default in

a

...

...

future GHC20XX then I suppose it's OK.

If it's backported to 9.2, then code wanting to use it would need to have a `ghc >= 9.2.4` constraint in the `.cabal` file, which is a bit unusual. We don't normally add new language features in a patchlevel release. But this isn't a strong argument for not doing it I guess - you would need that constraint if you relied on some bug that was fixed in 9.2.4 too.

Cheers Simon

On Mon, 20 Jun 2022 at 14:56, Spiwack, Arnaud < arnaud.spiwack@tweag.io> wrote:

...

Dear all,

The Deep Subsumption proposal [ https://github.com/ghc-proposals/ghc-proposals/pull/511 ] proposes a new extension, -XDeepSubsumption, which, when activated, partially reverts the changes from the Simplified Subsumption proposal.

The Simplified Subsumption breaks more programs than anticipated. Many don't see any benefit from Simplified Subsumption, just the breakage, and don't like the eta-expansion that it forces.

-XDeepSubsumption, when activated, restores deep skolemisation and co/contra-variance of the function arrow (but not deep instantiation, which doesn't affect the observed breakage). The patch already exists for it, and is about 400loc.

There are two interesting highlights for me. - It is proposed that -XDeepSubsumption is activated by default in Haskell98 and Haskell2010, but not GHC2021. -XDeepSubsumption is orthogonal to Haskell2010, as far as I can tell, but it gives a cut-off point from which the recommended behaviour (-XNoDeepSubsumption) is the default. - Even with -XDeepSubsumption, the Quick Look algorithm assumes that

...

...

...

...

The authors also have one unresolved question that I'm bringing to

...

...

...

...

---

Despite the fact that this extension is decidedly fork-like, and

On Thu, Jun 30, 2022, at 09:50, Spiwack, Arnaud wrote: library authors. the function arrow is invariant. The consequences of that are difficult to anticipate, but there is no known example of a bad behaviour due to that interaction yet. the committee's attention: should `-XDeepSubsumption` be backported to GHC 9.2? that it's a real possibility to see the community split around this (after all, the motivation for -XDeepSubsumption is a few libraries which were designed to leverage GHC's deep subsumption, and may very well stay that way in the foreseeable future). I recommend acceptance. Providing a path to backward compatibility seems to me like the right thing to do.

...

...

...

...

I also recommend backporting to GHC 9.2. It should essentially be

backward compatible, and providing an update path that doesn't go directly from 9.0 to 9.4 feels better to me.

...

_______________________________________________ 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

---

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