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

[Simon Peyton Jones]

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 <eric at seidel.io> 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
>
> On Thu, Jun 30, 2022, at 09:50, Spiwack, Arnaud wrote:
> > Eric,
> >
> > After the exchange on Github: are you still hesitant?
> >
> > On Sun, Jun 26, 2022 at 3:24 PM Eric Seidel <eric at seidel.io> 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.
> >>
> >> 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
> >> _______________________________________________
> >> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220630/b65396c8/attachment-0001.html>