ghc-steering-committee

Download

ghc-steering-committee@haskell.org

January 2023

8 participants
12 discussions

Why not?, rather than, why?
by Joachim Breitner 03 Jan '23

03 Jan '23

Hello Committee and Community, occasionally we have meta-discussions about GHC language extensions: Should they be allowed to be fork-like, where some extensions are unlikely to be used together and some stay opt-in forever? Or should (ideally) every extension be on track to become on-by-default. Of course there are a few “old” extensions that by their very nature are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the obvious candidates). Let’s put them aside for this discussion. I’d wager that if we’d introduce them these days, they wouldn’t be language extensions in the first place, but maybe modifiers on the module. I am mostly in the camp “every extension should be on track to become default (or be discarded)”. Once a language feature has been proven useful and reasonable stable, I see little value in requiring programmers to jump through hoops to use them. Is that the prevalent view here as well, or do we have a strong camp saying that our current “pick-and-choose” approach to language features is actually a good thing in its own (and not just a necessary nuisance)? If we assume the former, then maybe it would be worth to frame the discussion around new language extensions, and the discussion about which language extensions become default, around that vision. Concretely: * A new language proposal should not just be good enough for “worth building for those who explicitly turn it on”, but really ought convince as “this will make Haskell better for all” (and not just “a Haskell”). * Most new language features should probably not on by default initially, as usual, and are initially experimental. But then the proposal, and if accepted the documentation of the extension, should as explicit as possible explain why it is not yet default: What needs to happen for _this_ extension to be considered ready – or judged negatively and put on a track towards removal. This could be something like “been available for n releases, been stable for m releases”. (I wonder what other kind of criteria to expect here?) * The process for defining GHC20xx would then become very different: We’d go through all experimental extensions, check if the criteria are satisfied, maybe apply some common sense if the criteria are still good ones, and turn it on if so. This may turn the process to be more structured and maybe more predictable, and hopefully reduces the number of non-default extensions developers have to make a decision about (probably good). But it does raise the bar for new language features (is that good?). And, if applied consequently, it suggests to deprecate and eventually remove extensions that turn out to not be default-worthy after all (that’s kinda harsh)? As you can see I am a bit unsure about what the criteria are that we could put in the docs. Are they really different for different extensions? But the fact that its hard to come up right now with a concrete reason why extension X is not yet the default does point to a hole in our thinking and our process! And it is the same question that we face when discussing GHC20xx. So I guess what I am proposing here is: Have that discussion (when is it ready?) already when accepting a proposal, and document it in clear sight for our users, rather than have it over and over when debating GHC20xx. This is not a concrete (meta-)proposal, but hopefully tasty food for thought. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

7 22

#511 Deep Subsumption, recommendation: accept
by Spiwack, Arnaud 02 Jan '23

02 Jan '23

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.

5 8