<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">My views here:<div class=""><br class=""></div><div class="">* This whole push is like weeding an overgrown garden. Weeding is rarely the highest-priority task -- but if you never do it, the lack of care shows. I'm in support of doing *something* here.</div><div class="">* I think our users would benefit most from a clear delineation of the status of the various extensions. There are two challenges here: defining the categories and then doing the categorization. I believe this trek (led heroically by Arnaud) is about tackling that first challenge. David's proposal is also squarely in this space</div><div class="">* I'm against doing anything backward-incompatible about extensions. Extensions are generally seen as bureaucratic overhead; causing breakage because of them would be pedantry run amok. But the various ideas already proposed all sound like the could work to reduce the number of extensions while not causing backward incompatibility.</div><div class=""><br class=""></div><div class="">Richard</div><div class=""><br class=""></div><div class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Jul 17, 2023, at 6:16 AM, Moritz Angermann <<a href="mailto:moritz.angermann@gmail.com" class="">moritz.angermann@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="auto" class="">My view is, I don’t have much of a concrete opinion on this. I *do* have a very strong belief around backwards compatibility. I think that the constant churn that breaking changes cause are a major detriment to Haskell adoption. If I were in a position to make a technological decision. I’m not sure I’d be able to choose Haskell.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">I do think we have *way* too many extensions, and their interaction is hard to understand for new developers. I also think we should put a lot of the new developments (research compiler) behind a -DRESEARCH or -DEXPERIMENTAL flags and have separate binary distributions for those, clearly marked as such.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">But all this is orthogonal to this.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Reducing the amount of language extension complexities, by building groupings seems sensible. Having this come along with the compiler suggesting upgrading to language groups (GHC20XX) to reduce a lot of extension noise in files and better understood extensions interaction (ideally with the compiler providing the relevant patches or auto migration), would be something I consider sensible. </div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Removing extensions that lead to existing, but then broken code is something I’m *highly* opposed to. With lengthily deprecation cycles and some monitoring across the ecosystem this might be doable. I will however oppose none or short deprecation cycles.</div><div dir="auto" class=""><br class=""></div><div dir="auto" class="">Ultimately for the specific choice which extensions are grouped, and how, I’m not the right person to ask.</div><div dir="auto" class=""><br class=""></div><div class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 17 Jul 2023 at 10:53 AM, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" class="">simon.peytonjones@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr" class=""><div class="gmail_default" style="font-family:tahoma,sans-serif">My personal view is this. </div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul style="font-family:tahoma,sans-serif" class=""><li style="font-family:tahoma,sans-serif" class="">I find it hard to bring energy to this meta-conversation about extension policy. For me it's a funny combination of too abstract (what are we trying to achieve?) and too detailed (<i style="font-family:tahoma,sans-serif" class="">thirteen </i>possible use cases for each extension?).</li><li style="font-family:tahoma,sans-serif" class="">My general position is: let's define well-specified extensions, and let users choose which ones to use.</li><li style="font-family:tahoma,sans-serif" class="">I'm not against grouping them into GHC20xx groups, but I don't have a strong view about what should be in which groups. My instinct is to produce GHC20xx rather infrequently, much less than annually.<br class=""></li><li style="font-family:tahoma,sans-serif" class="">David's recent <a href="https://github.com/ghc-proposals/ghc-proposals/pull/601" target="_blank" style="font-family:tahoma,sans-serif" class="">extension policy proposal </a>makes sense to me. It is simple, concrete, and actionable.</li></ul><div style="font-family:tahoma,sans-serif" class="">If all this is important to others I'm not against continuing the conversation. But if it were me I'd just focus around agreeing David's proposal (if there is general support), and then let it be.</div><div style="font-family:tahoma,sans-serif" class=""><br class=""></div><div style="font-family:tahoma,sans-serif" class="">None of this is to criticise Arnaud and Joachim's work in herding cats. Thank you -- it's a tricky topic! I'm just not sure that it is the highest priority problem. But: remember that I am an out-lier. This conversation mostly impacts users, and I am unrepresentative of that constituency.</div></div></div><div dir="ltr" class=""><div class="gmail_default" style="font-family:tahoma,sans-serif"><div style="font-family:tahoma,sans-serif" class=""><br class=""></div><div style="font-family:tahoma,sans-serif" class=""><br class=""></div><div style="font-family:tahoma,sans-serif" class="">Simon<br class=""></div></div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 17 Jul 2023 at 09:40, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank" class="">arnaud.spiwack@tweag.io</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr" class=""><div class="">This discussion seems to be of little interest to most of us. I must confess that I'm quite surprised: I expected a rather heated debate. To try and get a better understanding of where everybody stands, it would help me to have everyone post even a short comment, even half-baked, expressing their sentiment on the issue.</div><div class=""><br class=""></div><div class="">Do pay attention to Joachim's idea, which is not in my original email, whereby extensions could only be made valid under a subset of base languages (Haskell98, Haskell2010, GHC20xx).</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank" class="">simon.peytonjones@gmail.com</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr" class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div class="gmail_default" style="font-family:tahoma,sans-serif">
A question which can matter as part of this discussion is how much of a maintenance burden is having so many extensions?
</div></blockquote><div class=""><br class=""></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Generally, not much provided they are well-designed and orthogonal. Some flag-testing would disappear if the feature is permanently on. But not much complexity beyond that, usually.<br class=""></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br class=""></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Simon</div></div><br class=""><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank" class="">arnaud.spiwack@tweag.io</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;padding-left:1ex;border-left-color:rgb(204,204,204)"><div dir="ltr" class=""><div dir="ltr" class=""><div class=""><font size="4" style="" class=""><b class="">@Chris:</b></font><br class=""></div><div class=""></div></div><div class="">That's a long email 🙂. I think that when people complain about committees, what they complain about is too many people deciding, not too few. At any rate, as the GHC steering committee we are the designated caretakers of GHC's flavour of Haskell. We are required to make decisions on proposals, and often asked to consult on what the best course of action for a proposal is. We use a set of principles as guides. Reducing the number of dialects of GHC can either be a goal or a non-goal. But the only alternative to choosing is not making a choice. And we'd be left in the current situation, where different committee members pull in different directions based on what extensions mean for them, and whether a proposal is accepted in a shape or another is largely dependent on which committee member had more brain cycles that week. Some of us have started this process of thinking deeply about extensions because we observed that there was a disconnect within the committee. And we believe that we owe the community better than this.</div><div class=""><br class=""></div><div class="">That being said, I'm not advocating or even proposing sweeping changes (a big change in policy would require, like any, a proposal). I'm asking us to dream a little together and think about what we believe would be most beneficial for the language. The main outcome that I'm trying to achieve is a new set of principles relating to extensions.</div><div class=""><br class=""></div><div class=""><font size="4" style="" class=""><b class="">@Joachim/@Simon:</b></font></div><div class="">I think both of you are bringing concern about backward compatibility. I think there are two questions:</div><div class="">1. Moving forward, we could advertise extensions as being temporary, and if you use them, you should expect to have to rewrite part of your code in the future. Is the extra work worth it?
</div><div class="">2. All the extensions in the past that we've been used to turn on on a fine-grain basis represent an enormous amount of libraries. Some are basically unmaintained, having been robust enough to go untouched for 10+ years. Rewriting this would be a tremendous effort. Is the extra work worth it?<br class=""></div><div class=""><br class=""></div><div class="">I take your comments as saying that the answer to (2) is almost certainly “no”. What's your answer to (1)? I can see an argument for saying that Haskell being a research language, extensions take longer than, say, in Rust, to be eventually rolled in. As such, we actually expect many to have extensions turned on, and for long enough that it would become a liability to erase the extension in the future.<br class=""></div><div class=""><br class=""></div><div class="">One difficulty is that it's rather fraught to let code with `-XSomeExtension` compile while not documenting what `-XSomeExtension` does. We could make it conspicuous in the manual that the extension is deprecated. But would `--show-options` also contain it? We also need to make sure that the deprecated extension is not autocompleted by IDEs (I guess this is a setting for GHCi). I think this is started to look like the Haskell Foundation's Stability Working Group's proposal mentioned above.</div><div class=""><br class=""></div><div class=""><font size="4" style="" class=""><b class="">@Joachim:</b></font><br class=""></div><div class=""><a class="gmail_plusreply" id="m_1764085822103808292m_7611511565404594576m_543098773165686283m_851995551079359170m_3344189753353392971plusReplyChip-4"></a></div><div class=""></div><div class="">The idea of having extensions work only against certain languages is intriguing. I think it needs some refinement: First, -XFuzzyTypes would work against GHC2024 or later, until it's folded into a GHC20xx. And, probably, you'll still want to be able to call `-XNoFuzzyTypes` on some of the GHC20xx where it is folded (maybe just 1), at least if it causes some compatibility issues (I don't think -XDerivingFunctor is of the sort), in order to smooth out transition.</div><div class=""><br class=""></div><div class="">Another question on this approach is: how would the user guide present this information without flooding the reader with extensions that don't apply to the GHC20xx they're using?</div><div class=""><br class=""></div><div class=""><font size="4" style="" class=""><b class="">@all</b></font>:<br class=""></div><div class="">A question which can matter as part of this discussion is how much of a maintenance burden is having so many extensions? From a pure implementation-of-GHC point of view. Personally, it's never really been in my way (which may simply mean that I don't contribute a lot), so I'm focussing, in this discussion, on the impact on Haskell programmers. But the impact on GHC developers is definitely relevant.<br class=""></div><div class=""></div><div class=""><br class=""></div><div class=""><span class="gmail_signature_prefix">-- </span><br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class="">Arnaud Spiwack<br class="">Director, Research at <a href="https://moduscreate.com/" rel="noopener noreferrer" target="_blank" class="">https://moduscreate.com</a> and <a href="https://tweag.io/" rel="noopener noreferrer" target="_blank" class="">https://tweag.io</a>.</div></div></div></div>
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div>
</blockquote></div><br clear="all" class=""><br class=""><span class="gmail_signature_prefix">-- </span><br class=""><div dir="ltr" class="gmail_signature"><div dir="ltr" class="">Arnaud Spiwack<br class="">Director, Research at <a href="https://moduscreate.com/" rel="noopener noreferrer" target="_blank" class="">https://moduscreate.com</a> and <a href="https://tweag.io/" rel="noopener noreferrer" target="_blank" class="">https://tweag.io</a>.</div></div>
</blockquote></div>
_______________________________________________<br class="">
ghc-steering-committee mailing list<br class="">
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank" class="">ghc-steering-committee@haskell.org</a><br class="">
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank" class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br class="">
</blockquote></div></div>
_______________________________________________<br class="">ghc-steering-committee mailing list<br class=""><a href="mailto:ghc-steering-committee@haskell.org" class="">ghc-steering-committee@haskell.org</a><br class="">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br class=""></div></blockquote></div><br class=""></div></body></html>