Language Extension Policy – Round 3 - ghc-steering-committee

Language Extension Policy – Round 3

Arnaud Spiwack

7 Jul 2023 7 Jul '23

3:43 a.m.

Dear all, 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. 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. 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. Let's explore what it would mean for an extension to be removed. - 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) - The programmer can't turn the extension on or off directly - 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) - 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. - 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. - Am I forgetting something? 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. 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. [1] https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmeco... -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Attachments:

attachment.html (text/html — 3.3 KB)

Show replies by date

Simon Peyton Jones

7 Jul 7 Jul

4:20 a.m.

...

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.

I don't have a strong opinion myself either way. But I am a little concerned that if we decided to do it, we'd then have to pour energy into implementation (admittedly not hard, just deleting extension-parsing code and updating documentation) and publicity. More controversially, zillions of library authors would be forced to update their packages. In pursuit of what? A compiler that can do slightly less than it could before the change. So I'm a bit sceptical. What would sway me is if our users consistently said "yes! Please remove those extensions in favour of GHC20xx". The question is concrete enough that we could survey our users, and I think we probably should before doing this, even if there is a consensus among us. Simon On Fri, 7 Jul 2023 at 08:44, Arnaud Spiwack wrote:

...

Dear all,

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.

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.

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.

Let's explore what it would mean for an extension to be removed. - 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) - The programmer can't turn the extension on or off directly - 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) - 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. - 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. - Am I forgetting something?

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.

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.

[1] https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmeco...

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Chris Dornan

7:59 a.m.

Arnoud, Sorry, I do have a problem with this process. 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. 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.) 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. 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. 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. 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. 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. 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. I don't want to come across as all negative here so I will propose an alternative way of approaching reform. An Alternative 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. 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. 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). 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. Chris

...

On 7 Jul 2023, at 08:43, Arnaud Spiwack wrote:

Dear all,

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.

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.

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.

Let's explore what it would mean for an extension to be removed. - 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) - The programmer can't turn the extension on or off directly - 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) - 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. - 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. - Am I forgetting something?

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.

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.

[1] https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmeco...

-- Arnaud Spiwack Director, Research at https://moduscreate.com https://moduscreate.com/ and https://tweag.io https://tweag.io/. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Joachim Breitner

8 Jul 8 Jul

8:34 a.m.

Hi, good input! Am Freitag, dem 07.07.2023 um 09:43 +0200 schrieb Arnaud Spiwack:

...

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.

TL;DR: Yes, if “remove” means “remove from sight from developers working on “modern” code; but not when compiling “old” code. this indeed sounds surprisingly hard, and it may depend on what “removes” mean. I do believe that the 2^n complexity is hurting us. But I also do believe that not being to compile old code with new compilers is hurting us. So on the one hand I hope that in a hopefully not so distant future, nobody on up-to-day code will even have to know that -XDeriveFunctor was a thing. It should just work by default. The documentation should frame it as a “normal” feature, not an “extension”. And if the compiler encounters a Haskell2010 module that tries to derive Functor, it should probably indeed suggest “please use GHC20xx”. On the other hand, as long as we can afford the engineering effort, we can keep supporting Haskell98+DeriveFunctor, so that existing code keeps working. This already helps a bit fighting the 2^n mental complexity, because the set of extensions a (non-archaeological) developer encounters is smaller. It further help with the 2^n implementation complexity if we’d say * Old extensions cannot be turned off. So if you have choose LANGAUGE GHC2024 as the language edition, you simply don’t get to select -XNoDeriveFunctor. (Maybe we offer _warnings_ if people want help avoiding some feature.) * New extensions can only be used with new based editions. If we get add -XFuzzyTypes next year, this feature is only available in modules that have GHC2024 as the base language edition This means, for example, that nobody has to worry about the interaction between FuzzyTypes with NoDeriveFunctor, and the 2^n explosion gets better. (I think this is very close to what you are saying?) Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Arnaud Spiwack

10 Jul 10 Jul

10:13 a.m.

*@Chris:* 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. 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. *@Joachim/@Simon:* I think both of you are bringing concern about backward compatibility. I think there are two questions: 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? 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? 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. 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. *@Joachim:* 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. 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? *@all*: 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. -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Simon Peyton Jones

10:25 a.m.

...

A question which can matter as part of this discussion is how much of a maintenance burden is having so many extensions?

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. Simon On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack wrote:

...

*@Chris:* 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.

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.

*@Joachim/@Simon:* I think both of you are bringing concern about backward compatibility. I think there are two questions: 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? 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?

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.

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.

*@Joachim:* 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.

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?

*@all*: 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.

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Arnaud Spiwack

17 Jul 17 Jul

4:39 a.m.

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. 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). On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

A question which can matter as part of this discussion is how much of a

...
maintenance burden is having so many extensions?

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.

Simon

On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack wrote:

...
*@Chris:* 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.

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.

*@Joachim/@Simon:* I think both of you are bringing concern about backward compatibility. I think there are two questions: 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? 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?

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.

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.

*@Joachim:* 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.

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?

*@all*: 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.

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Simon Peyton Jones

4:52 a.m.

My personal view is this. - 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 (*thirteen *possible use cases for each extension?). - My general position is: let's define well-specified extensions, and let users choose which ones to use. - 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. - David's recent extension policy proposal https://github.com/ghc-proposals/ghc-proposals/pull/601makes sense to me. It is simple, concrete, and actionable. 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. 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. Simon On Mon, 17 Jul 2023 at 09:40, Arnaud Spiwack wrote:

...

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.

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).

On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...
A question which can matter as part of this discussion is how much of a

...
maintenance burden is having so many extensions?

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.

Simon

On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack wrote:

...
*@Chris:* 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.

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.

*@Joachim/@Simon:* I think both of you are bringing concern about backward compatibility. I think there are two questions: 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? 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?

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.

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.

*@Joachim:* 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.

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?

*@all*: 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.

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Moritz Angermann

6:16 a.m.

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. 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. But all this is orthogonal to this. 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. 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. Ultimately for the specific choice which extensions are grouped, and how, I’m not the right person to ask. On Mon, 17 Jul 2023 at 10:53 AM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

My personal view is this.

- 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 (*thirteen *possible use cases for each extension?). - My general position is: let's define well-specified extensions, and let users choose which ones to use. - 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. - David's recent extension policy proposal https://github.com/ghc-proposals/ghc-proposals/pull/601makes sense to me. It is simple, concrete, and actionable.

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.

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.

Simon

On Mon, 17 Jul 2023 at 09:40, Arnaud Spiwack wrote:

...
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.

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).

On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...
A question which can matter as part of this discussion is how much of a

...
maintenance burden is having so many extensions?

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.

Simon

On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack wrote:

...
*@Chris:* 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.

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.

*@Joachim/@Simon:* I think both of you are bringing concern about backward compatibility. I think there are two questions: 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? 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?

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.

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.

*@Joachim:* 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.

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?

*@all*: 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.

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Richard Eisenberg

21 Jul 21 Jul

1:48 p.m.

My views here: * 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. * 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 * 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. Richard

...

On Jul 17, 2023, at 6:16 AM, Moritz Angermann wrote:

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.

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.

But all this is orthogonal to this.

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.

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.

Ultimately for the specific choice which extensions are grouped, and how, I’m not the right person to ask.

On Mon, 17 Jul 2023 at 10:53 AM, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote: My personal view is this. 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 (thirteen possible use cases for each extension?). My general position is: let's define well-specified extensions, and let users choose which ones to use. 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. David's recent extension policy proposal https://github.com/ghc-proposals/ghc-proposals/pull/601makes sense to me. It is simple, concrete, and actionable. 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.

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.

Simon

On Mon, 17 Jul 2023 at 09:40, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote: 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.

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).

On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote: A question which can matter as part of this discussion is how much of a maintenance burden is having so many extensions?

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.

Simon

On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote: @Chris: 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.

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.

@Joachim/@Simon: I think both of you are bringing concern about backward compatibility. I think there are two questions: 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? 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?

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.

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.

@Joachim: <> 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.

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?

@all: 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.

-- Arnaud Spiwack Director, Research at https://moduscreate.com https://moduscreate.com/ and https://tweag.io https://tweag.io/. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com https://moduscreate.com/ and https://tweag.io https://tweag.io/. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Arnaud Spiwack

31 Jul 31 Jul

4:41 a.m.

I think we've gathered as much data as we can here. Eventually, we'll probably want to use this thread to come up with a GHC proposal along the lines of what Joachim came up with (extensions only apply to certain languages), as it seems like it may be very desirable and there's a clear consensus that retiring extensions altogether is undesirable. I'm not sure yet what our next round of discussion will be about. I'll be on holiday next week and the week after, so I'd like to start something before then (but I'm making no promises: I need to collect my thoughts). On Fri, 21 Jul 2023 at 19:49, Richard Eisenberg wrote:

...

My views here:

* 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. * 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 * 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.

Richard

On Jul 17, 2023, at 6:16 AM, Moritz Angermann wrote:

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.

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.

But all this is orthogonal to this.

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.

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.

Ultimately for the specific choice which extensions are grouped, and how, I’m not the right person to ask.

On Mon, 17 Jul 2023 at 10:53 AM, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...
My personal view is this.

- 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 (*thirteen *possible use cases for each extension?). - My general position is: let's define well-specified extensions, and let users choose which ones to use. - 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. - David's recent extension policy proposal https://github.com/ghc-proposals/ghc-proposals/pull/601makes sense to me. It is simple, concrete, and actionable.

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.

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.

Simon

On Mon, 17 Jul 2023 at 09:40, Arnaud Spiwack wrote:

...
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.

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).

On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...
A question which can matter as part of this discussion is how much of a

...
maintenance burden is having so many extensions?

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.

Simon

On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack wrote:

...
*@Chris:* 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.

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.

*@Joachim/@Simon:* I think both of you are bringing concern about backward compatibility. I think there are two questions: 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? 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?

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.

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.

*@Joachim:* 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.

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?

*@all*: 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.

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io.

Adam Gundry

1 Aug 1 Aug

3:16 a.m.

Apologies for the delay in responding, I've been away and am generally busy thanks to school holidays! I haven't been through this thread in detail, but to set out my overall position: * Clearly categorising extensions by stability (along the lines of #601) seems like an obvious win. * I think it would be a good idea for someone to rewrite the user's guide so that it represents the latest GHC20xx as the base language (e.g. so BangPatterns are documented as a feature of the language, with a brief mention that -XNoBangPatterns exists). We could rename chapter 6 "Language extensions" to be "The language GHC supports". I suspect it's probably better to keep it organised by topic rather than bifurcating it into GHC20xx vs non-GHC20xx features, not least because in some cases it may need to document the fact that the extension's status changed over time. * Error message recommendations can surely be improved to be more sensible (not telling users to enable certain extensions). * I'm sceptical that reducing choice (e.g. GHC2024 mandating certain extensions but prohibiting others, or making it impossible to disable certain extensions) is really valuable. We can certainly forbid actually problematic interactions (by making it an error to enable two features that don't make sense together). But I'm unconvinced that we get any real conceptual or implementation benefit from a general prohibition. Cheers, Adam On 31/07/2023 09:41, Arnaud Spiwack wrote:

...

I think we've gathered as much data as we can here. Eventually, we'll probably want to use this thread to come up with a GHC proposal along the lines of what Joachim came up with (extensions only apply to certain languages), as it seems like it may be very desirable and there's a clear consensus that retiring extensions altogether is undesirable.

I'm not sure yet what our next round of discussion will be about. I'll be on holiday next week and the week after, so I'd like to start something before then (but I'm making no promises: I need to collect my thoughts).

On Fri, 21 Jul 2023 at 19:49, Richard Eisenberg mailto:lists@richarde.dev> wrote:

My views here:

* 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. * 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 * 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.

Richard

...
On Jul 17, 2023, at 6:16 AM, Moritz Angermann mailto:moritz.angermann@gmail.com> wrote:

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.

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.

But all this is orthogonal to this.

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.

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.

Ultimately for the specific choice which extensions are grouped, and how, I’m not the right person to ask.

On Mon, 17 Jul 2023 at 10:53 AM, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

My personal view is this.

* 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 (/thirteen /possible use cases for each extension?). * My general position is: let's define well-specified extensions, and let users choose which ones to use. * 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. * David's recent extension policy proposal https://github.com/ghc-proposals/ghc-proposals/pull/601makes sense to me. It is simple, concrete, and actionable.

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.

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.

Simon

On Mon, 17 Jul 2023 at 09:40, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote:

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.

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).

On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

A question which can matter as part of this discussion is how much of a maintenance burden is having so many extensions?

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.

Simon

On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote:

*@Chris:* 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. 2^n - 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.

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.

*@Joachim/@Simon:* I think both of you are bringing concern about backward compatibility. I think there are two questions: 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? 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?

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.

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.

*@Joachim:* 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.

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?

*@all*: 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.

-- Arnaud Spiwack Director, Research at https://moduscreate.com https://moduscreate.com/ and https://tweag.io https://tweag.io/. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com https://moduscreate.com/ and https://tweag.io https://tweag.io/.

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Arnaud Spiwack Director, Research at https://moduscreate.com https://moduscreate.com and https://tweag.io https://tweag.io.

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England

Simon Marlow

30 Aug 30 Aug

6:43 a.m.

Apologies also from me, I took the whole 6-week school holidays off work and I'm only just getting back into it. On Tue, 1 Aug 2023 at 08:17, Adam Gundry wrote:

...

* I think it would be a good idea for someone to rewrite the user's guide so that it represents the latest GHC20xx as the base language

I think even if we do nothing else, this would be a great step forwards. Right now, extensions are the first-class mechanism, and GHC20xx is expressed as a group of extensions. Ideally it should be the other way around. If we made a few changes to documentation and error messages to steer people towards GHC20xx and away from extensions, in the long term that would have the effect of making explicit extensions less common and more of an experimental/advanced feature. GHC20xx would be the norm, and code that people encounter would often be in one of the (few) GHC20xx dialects. That would simplify things from the user's perspective, with zero impact on the implementation. We seem to be more worried by the user-facing impact of extension-fatigue rather than the implementation complexity of making 2^n combinations work (going by Simon's comments, the implementation impact isn't really a problem). Cheers Simon

...

(e.g. so BangPatterns are documented as a feature of the language, with a brief mention that -XNoBangPatterns exists). We could rename chapter 6 "Language extensions" to be "The language GHC supports". I suspect it's probably better to keep it organised by topic rather than bifurcating it into GHC20xx vs non-GHC20xx features, not least because in some cases it may need to document the fact that the extension's status changed over time.

* Error message recommendations can surely be improved to be more sensible (not telling users to enable certain extensions).

* I'm sceptical that reducing choice (e.g. GHC2024 mandating certain extensions but prohibiting others, or making it impossible to disable certain extensions) is really valuable. We can certainly forbid actually problematic interactions (by making it an error to enable two features that don't make sense together). But I'm unconvinced that we get any real conceptual or implementation benefit from a general prohibition.

Cheers,

Adam

On 31/07/2023 09:41, Arnaud Spiwack wrote:

...
I think we've gathered as much data as we can here. Eventually, we'll probably want to use this thread to come up with a GHC proposal along the lines of what Joachim came up with (extensions only apply to certain languages), as it seems like it may be very desirable and there's a clear consensus that retiring extensions altogether is undesirable.

I'm not sure yet what our next round of discussion will be about. I'll be on holiday next week and the week after, so I'd like to start something before then (but I'm making no promises: I need to collect my thoughts).

On Fri, 21 Jul 2023 at 19:49, Richard Eisenberg mailto:lists@richarde.dev> wrote:

My views here:

* 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. * 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 * 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.

Richard

...
On Jul 17, 2023, at 6:16 AM, Moritz Angermann mailto:moritz.angermann@gmail.com> wrote:

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.

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.

But all this is orthogonal to this.

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.

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.

Ultimately for the specific choice which extensions are grouped, and how, I’m not the right person to ask.

On Mon, 17 Jul 2023 at 10:53 AM, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

My personal view is this.

* 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 (/thirteen /possible use cases for each

extension?).

...
* My general position is: let's define well-specified extensions, and let users choose which ones to use. * 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. * David's recent extension policy proposal https://github.com/ghc-proposals/ghc-proposals/pull/601makes

sense to me. It is simple, concrete, and actionable.

...
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.

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.

Simon

On Mon, 17 Jul 2023 at 09:40, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io>

wrote:

...
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.

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).

On Mon, 10 Jul 2023 at 16:26, Simon Peyton Jones mailto:simon.peytonjones@gmail.com> wrote:

A question which can matter as part of this discussion is how much of a maintenance burden is having so many extensions?

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.

Simon

On Mon, 10 Jul 2023 at 15:14, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote:

*@Chris:* 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. 2^n - 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.

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.

*@Joachim/@Simon:* I think both of you are bringing concern about backward compatibility. I think there are two questions: 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? 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?

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.

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.

*@Joachim:* 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.

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?

*@all*: 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.

-- Arnaud Spiwack Director, Research at https://moduscreate.com https://moduscreate.com/ and https://tweag.io https://tweag.io/. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>

...
-- Arnaud Spiwack Director, Research at https://moduscreate.com https://moduscreate.com/ and https://tweag.io https://tweag.io/.

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>

...
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org mailto:ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>

...
-- Arnaud Spiwack Director, Research at https://moduscreate.com https://moduscreate.com and https://tweag.io https://tweag.io.

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/

Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

629

Age (days ago)

683

Last active (days ago)

List overview

Download

12 comments

8 participants

participants (8)

Adam Gundry
Arnaud Spiwack
Chris Dornan
Joachim Breitner
Moritz Angermann
Richard Eisenberg
Simon Marlow
Simon Peyton Jones

Language Extension Policy – Round 3

tags

participants (8)