<div dir="ltr"><div>Eric,</div><div><br></div><div>After the exchange on Github: are you still hesitant?<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Jun 26, 2022 at 3:24 PM Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<br>
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.<br>
<br>
On Tue, Jun 21, 2022, at 05:47, Simon Marlow wrote:<br>
> I'm never a fan of fork-like things, but as long as we're clear that <br>
> -XDeepSubsumption is not recommended and will not be on by default in a <br>
> future GHC20XX then I suppose it's OK.<br>
><br>
> If it's backported to 9.2, then code wanting to use it would need to <br>
> have a `ghc >= 9.2.4` constraint in the `.cabal` file, which is a bit <br>
> unusual. We don't normally add new language features in a patchlevel <br>
> release. But this isn't a strong argument for not doing it I guess - <br>
> you would need that constraint if you relied on some bug that was fixed <br>
> in 9.2.4 too.<br>
><br>
> Cheers<br>
> Simon<br>
><br>
> On Mon, 20 Jun 2022 at 14:56, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br>
>> Dear all,<br>
>> <br>
>> The Deep Subsumption proposal [ <a href="https://github.com/ghc-proposals/ghc-proposals/pull/511" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/511</a> ] proposes a new extension, -XDeepSubsumption, which, when activated, partially reverts the changes from the Simplified Subsumption proposal.<br>
>> <br>
>> 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.<br>
>> <br>
>> -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.<br>
>> <br>
>> There are two interesting highlights for me.<br>
>> - 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.<br>
>> - Even with -XDeepSubsumption, the Quick Look algorithm assumes that 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.<br>
>> <br>
>> The authors also have one unresolved question that I'm bringing to the committee's attention: should `-XDeepSubsumption` be backported to GHC 9.2?<br>
>> <br>
>> ---<br>
>> <br>
>> 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, 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.<br>
>> <br>
>> 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.<br>
>> _______________________________________________<br>
>> ghc-steering-committee mailing list<br>
>> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
>> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>