<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div dir="auto" style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Arnoud,<div><br></div><div>Sorry, I do have a problem with this process.</div><div><br></div><div>I think this committee needs to be really careful about trying to, in effect, rationalise and reshape Haskell. You have expressed here and elsewhere I think how difficult this process is. If we are going to make any progress I think we need a measure of candour added to this discussion that I feel is currently missing.</div><div><br></div><div>There appears to be a widespread feeling that Haskell is suffering from committee-itus, leading us to a bloated language, causing us to lose out to more nimble competitors that can rely on industrial benefactors to weald the iron fist and shape a more compelling product -- which then proceeds to 'eat our lunch'. (We can probably see this kind of dialectic playing out in the wider world where democratic traditions are getting a bad rep with more streamlined autocratic methods gaining traction in the face of existential challenges.)</div><div><br></div><div>I want to float an alternative -- not necessarily one that I subscribe to -- but one that I think we should bear in mind. In this telling, the community has just settled down from the communal strife that nearly ended it immediately before the formation of the HF. With the effort put into dowsing those fires now starting to pay off, the community is starting to heal and gather for The Next Big Thing (TM). That creates a vacuum that is looking to be filled and inevitably folks are going to have visions about what the future of Haskell should be, and seek to propagate those in the wider community. To me it seems obvious, that unskilful initiatives will encounter pushback and could tip us into another round of conflict -- one that we can ill afford. If you want to see how easily this can happen just look at the tremendous difficulty the GHC team had in getting agreement for what I assumed was a really straightforward reorganisation of how the GHC team structures its internal libraries. It encountered strong pushback from the CLC and the resulting discussion was highly illuminating on many levels.</div><div><br></div><div>My takeaway is never try to short circuit messy consensus building on the grounds that we cannot afford it. What we should have learned by now is that this is an illusion, that we cannot afford to not build consensus. I think we should trust that we are all invested in the success of the wider project, that we are all rational and well intentioned. If we are having difficulty reaching consensus despite extensive open discussion then that is probably for a good reason, and not likely because of various shortcomings in the dissenters.</div><div><br></div><div>More specifically my problem with the process that we are undertaking is that I get the strong sense that although we are ostensibly embarking on a framework to make sense of GHC-Haskell language extensions, there is a push by those that subscribe to the Haskell-needs-rationalising thesis to use this process to rationalise GHC-Haskell going forward, and it makes me deeply uncomfortable. To be clear, I am not necessarily against rationalising GHC-Haskell -- just that if we are going to do it then it needs to be done super carefully (and probably incrementally). I think ff we are going to reshape GHC-Haskell then we are going to have to get everyone in the steering committee entirely on board, but also we will need to think about how build consensus in the wider community for such changes.</div><div><br></div><div>I have tried to indicate clearly in the discussion that I think GHC should be supporting pretty much every current use case. But when I read that we can see a kernel of support for something in 6 out of 10 board members and that should use that as the basis for the next round of refinement then I worry.</div><div><br></div><div>Something that I want to make clear is that I am not at all persuaded by an argument that we can see GHC is clearly being used for purpose X but that purpose could be fulfilled by some alternative tool (a linter say) so let's stop developers from being able to use GHC in this way and force them to use the alternative tools.</div><div><br></div><div>Even milder reforms like deleting extensions that clearly have been superseded should be done with great care. Thousands of packages that could require revision to work with modern GHCs and that can create significant organisational problems, never mind the social problems.</div><div><br></div><div>I don't want to come across as all negative here so I will propose an alternative way of approaching reform.</div><div><br></div><div>An Alternative</div><div><br></div><div>Why don't we approach this like we would refactor a codebase. The first phase in any refactoring is to invest a great deal of time and effort doing precisely nothing of course. Here we are reshaping the code according to our revised understanding of what the various modules should do and how they should be organised, but without changing the overall behaviour of the system. Done rightly, we can carry out our revolution non-disruptively until we are ready to make the actual change, at which point the change itself becomes almost trivial.</div><div><br></div><div>Applied to our situation: if we believe radical change is necessary then we are going to have to put in the hard yards to bring the community into alignment with our way of thinking but without disrupting anyone. It is very important to take disruption right off the table, otherwise you we just going to encounter vigorous pushback to even establishing a shared conceptual framework. This is especially true if you propose a new conceptual framework with a thinly disguised radical program at its core.</div><div><br></div><div>I am really proposing that we spend some time merely understanding how GHC and its language extensions are actually being used without any view to deciding what is a legitimate use or not. Getting agreement and buy-in for this will be challenging in itself (and incredibly valuable I might add).</div><div><br></div><div>But we have to do this in stages. Build the conceptual framework first, including the wider shared understanding of it. Then, and only then, contemplate making any disruptive change.</div><div><br></div><div>Chris</div><div><br></div><div><br><div><br><blockquote type="cite"><div>On 7 Jul 2023, at 08:43, Arnaud Spiwack <arnaud.spiwack@tweag.io> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr">Dear all,<br><br>For this round, I'd like to build on the results of last round [1]. One thing that strikes me in the results, bearing in mind that 6 out of 10 members answered the question directly, and that none of this is without dissent anyway, is that there seems to be a general feeling that extension should not stay forever.<br><br>What I'm reading is that most respondents seem to believe that when an extension becomes part of GHC20xx, it should be removed (with a deprecation period, I'd imagine): if you want the feature, use GHC20xx.<br><br>Now, before I explore this question further, I should acknowledge that this doesn't directly help answering the questions that I set to resolve when this all began. Namely, under what principles do we judge extensions (in particular whether a proposal should be one of several extensions). But I think it's likely to help. I'm starting with this conversation because it's relatively concrete, probably less controversial than other questions, and as such, I'm hoping that it'll help us discuss the more difficult questions with a little more understanding of what we collectively believe.<br><br>Let's explore what it would mean for an extension to be removed.<br>- The extension wouldn't appear in `$ ghc --show-options` (currently `$ ghc --show-options | grep '\-X'` has 268 lines, almost every extension accounts for 2 lines)<br>- The programmer can't turn the extension on or off directly<br>- The documentation, in the user manual, of the corresponding feature would be moved from the “Language extension” section to somewhere else (maybe a new section “Language features”? Not sure what is natural here)<br>- Error messages about the feature not being activated would stop suggesting you use the extension, but instead that you use one of the appropriate GHC20xx.<br>- For some extension, we could provide a warning (off by default) to allow those who want to avoid the corresponding to disallow it in their codebase. But certainly not all extensions would be turned into warnings: I don't anticipate anybody will want to specifically avoid -XBinaryLiteral for instance.<br>- Am I forgetting something?<br><br>It doesn't mean that the extension must disappear in the implementation of GHC: this is an implementation detail (maybe it'll be beneficial for some extensions to be removed and other not, I don't feel capable of anticipating this). But the extension would not be visible or accessible to the user.<br><br>Now the question is: ignoring the question of whether we have time to retroactively do this, does this look like this would be part of your ideal vision for GHC. If not, please argue.<br><br>[1] <a href="https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmecoSfhnvuE/edit?usp=sharing">https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmecoSfhnvuE/edit?usp=sharing</a><br clear="all"><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">Arnaud Spiwack<br>Director, Research at <a href="https://moduscreate.com/" rel="noopener noreferrer" target="_blank">https://moduscreate.com</a> and <a href="https://tweag.io/" rel="noopener noreferrer" target="_blank">https://tweag.io</a>.</div></div></div>
_______________________________________________<br>ghc-steering-committee mailing list<br>ghc-steering-committee@haskell.org<br>https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<br></div></blockquote></div><br></div></div></body></html>