[ghc-steering-committee] #511 Deep Subsumption, recommendation: accept

[Eric Seidel]

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.

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 at 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 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 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, 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 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