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

Language Extension Policy – Round 2

Arnaud Spiwack

19 Apr 2023 19 Apr '23

8:20 a.m.

Dear all, In Round 1', we have gathered no less than 13 use-cases (see below) found in the community for Haskellers to motivate the need for extensions. Some of these use-cases are specific to a pretty definite list of extensions, some are not. Some extensions fall squarely in one use-case, some don't. Use-cases are not a classification of extensions, they're a classification of justifications for extensions to exist. Surely we've missed some, but it's alright to not be fully exhaustive. In this next round, I want us to give our opinion, on each of these use-cases, on whether we believe that this use-case is best served by extension. My goal, in this round, is not necessarily to build consensus for a policy, but to discover where there is consensus, and where there is controversy, so that we can discuss the relevant use-cases in more detail. In this round, I'm asking you, for each X∈{1,…,13}, to answer the following questions: X.1: do you believe that this a use-case that GHC should support? (yes/no) X.2: regardless of your answer in X.1, if GHC supports this use-case, do you believe that this use-case is best served by extensions. (yes/no) X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) X.2.N: if you've answered “no” to X.2: what mechanism would you rather see supporting this use-case (free form) I'll be on holiday next week, and will tally the results on the first week on May. The 13 use-cases are 1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability) 2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language) 3. Restrict the use of novel features since the last established standard/report. 4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters) 5. Name/refer to a particular feature when talking/writing/searching about it. 6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax) 7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with. 8. Retain access to deprecated features to smooth out migration over the deprecation period. 9. Retain access to deprecated features indefinitely. 10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example) 11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too) 12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it) 13. CPP (this one is very unique isn't it?)

Attachments:

attachment.html (text/html — 3.3 KB)

Show replies by date

Joachim Breitner

20 Apr 20 Apr

5:41 a.m.

Hi, Am Mittwoch, dem 19.04.2023 um 14:20 +0200 schrieb Arnaud Spiwack:

...

The 13 use-cases are

1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability)

1: Yes, worthwhile usecase. 2: Yes, Extensions serve this well. 2Y: By definition GHC20xx doesn’t help, because it doesn’t touch experimental or unstable features.

...

2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language)

1: No, I don’t think that’s a task that the compiler is necessary best suited for. At least not at the current “accidential” complexity – if there was a push for real language levels as a first-class, well designed feature, things would be different. 2: No. They kinda work, but maybe warning flags are more suitable. 2N: Waring flags or, maybe better, external tools (hlint).

...

3. Restrict the use of novel features since the last established standard/report.

1: Yes, worthwhile to support. Although I’d phrase it dually: It’s worthwhile for GHC to support, in addition to “current GHC Haskell”, the standardized dialects. 2: Yes, kinda. 2Y: Yes, at least in the general sense that GHC20xx, like Haskell2021, selects a language dialect alltogether, instead of having to turn off and on individual flags.

...

4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters)

Same answers as for 2.

...

5. Name/refer to a particular feature when talking/writing/searching about it.

1: Yes, very useful to have names for things! 2: I’m unsure. The extension names work quite well. But if this would be come an actively supported use-case (rather than an accidential one), should we come up with names for existing things as well? (-XWhereBindings). It doens’t seem to be a good idea to couple “well- identified feature with a clear name” and “compiler flag”

...

6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax)

Again similar to 2. I don’t see anything wrong with GHC just accepting unicode syntax when it encounters them, just like it accepts non-ASCII variable names. (This is independent of whether GHC should print syntax in Unicode style unless asked to do it, but that’s not a language design question.)

...

7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with.

1: Yes, useful. 2: Possibly, but that would require a more defined story about backwards compatibility within an extension. Can we change extensions? Or only those that are somehow labeled to be more stable? 2Y: It could help if “being in GHC20xx” is used as a proxy for “kinda stable”, which is a prerequisite for this signallingto work reliably. 2N: That said, I don’t see much benefit of using this indirect compat signalling over just stating in the library which GHC versions it is known to work with, just like we do with library dependencies.

...

8. Retain access to deprecated features to smooth out migration over the deprecation period.

1: Yes, useful. Similar to question 3 2: Yes 2Y: Yes, by using an older GHC20xx one pins an older feature set, possibly including deprecated versions. This decouples “upgrading GHC” and “adopting the code base to the new dialect”, which should make life easier for developers.

...

9. Retain access to deprecated features indefinitely.

1: Unsure. Depends on how commonly used it is, and how expensive it is to carry around.

...

10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example)

1: I’m leaning to say no. Haskell + StrictData is a different language, and one that we can’t envision to be the default (I’d say). That use case should ideally be addressed in a different way that is a language extension, not a language change. 2: No 2N: Annotations maybe, or a new keyword?

...

11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too)

1: Strong yes. Barring ourselves from making changes that may affect some existing programs is no longer avoiding success at all costs. 2: Yes 2Y: Yes, definitely: It means that the programmer is in control when to apply a change like OverloadedStrings which may require some code changes.

...

12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it)

1: Yes. 2: No, a dedicated pragma would probably be cleaner, but willing to entertain that single odd case. It would also be more consistent to always _parse_ the TH syntax (to avoid breakage when it is enabled, and to make reading code less ambiguous), and simply fail if the pragma is not set given.

...

13. CPP (this one is very unique isn't it?)

1: Yes 2: Again, dedicated pragma might be cleaner. Also helps programs parsing Haskell programs if the information is _always_ local in the file. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Arnaud Spiwack

26 Apr 26 Apr

7 a.m.

Dear all, I'm currently on holiday. I've scheduled this email to be sent before I left. Remember to vote if you haven't voted yet: I'll be back next week and tally the results some time during said week. Let me take the opportunity to send in my votes. 1.1: yes 1.2: yes 1.2.Y: yes: extensions rolled in GHC20xx are clearly marked as no longer experimental. GHC20xx can have a stronger policy for backward compatibility clearly marking extensions which are at risk of making non-forward compatible code. 2.1: no 2.2: no 2.2.N: I think I'd push such code-style rules into a linter 3.1: no I think that the report has lost relevance in practice. Nobody is willing to come up with the next version, and GHC20xx has taken its place 3.2: yes 3.2.Y: no, I'd say GHC20xx embodies the opposite of this use-case 4.1: no 4.2: no 4.2.N: like (2), I'd rather use a linter 5.1: yes 5.2: no 5.2.N: I'd name things in the manual. Actually, this is something Haskell has historically been rather good at. 6.1: yes for those who can't be avoided (e.g. printing unicode, but not parsing unicode) 6.2: no 6.2.N: It should simply be a flag. E.g. for printing unicode in error messages this is something that you may want to configure globally for your machine rather than for a project. 7.1: yes 7.2: no, though extensions have proved decent at it, so not a hill I would die on 7.2.N: version bounds seem to me sufficient, and since they are still necessary, I don't see why we would need to pay attention to this aspect in the design of extensions. 8.1: yes 8.2: yes 8.2.Y: yes. As I imagine that pegging to a particular GHC20xx version would keep the deprecated feature going. 9.1: no, though I admit it can be argued. 9.2: yes 9.2.Y: yes, if we keep support GHC20xx version indefinitely we'd de facto keep deprecated behaviour indefinitely. 10.1: no 10.2: yes. Not that I think that extensions are a good way to do this, but I can't think of a better way. 10.2.Y: no 11.1: yes 11.2: yes 11.2.Y: yes, as these extensions can eventually become the standard behaviour. 12.1: yes 12.2: yes 12.2.Y: no 13.1: no (but this is obviously a ship that has long sailed) 13.2: yes 13.2.Y: no On Thu, 20 Apr 2023 at 11:42, Joachim Breitner wrote:

...

Hi,

Am Mittwoch, dem 19.04.2023 um 14:20 +0200 schrieb Arnaud Spiwack:

...
The 13 use-cases are

1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability)

1: Yes, worthwhile usecase. 2: Yes, Extensions serve this well. 2Y: By definition GHC20xx doesn’t help, because it doesn’t touch experimental or unstable features.

...
2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language)

1: No, I don’t think that’s a task that the compiler is necessary best suited for. At least not at the current “accidential” complexity – if there was a push for real language levels as a first-class, well designed feature, things would be different.

2: No. They kinda work, but maybe warning flags are more suitable.

2N: Waring flags or, maybe better, external tools (hlint).

...
3. Restrict the use of novel features since the last established standard/report.

1: Yes, worthwhile to support. Although I’d phrase it dually: It’s worthwhile for GHC to support, in addition to “current GHC Haskell”, the standardized dialects.

2: Yes, kinda. 2Y: Yes, at least in the general sense that GHC20xx, like Haskell2021, selects a language dialect alltogether, instead of having to turn off and on individual flags.

...
4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters)

Same answers as for 2.

...
5. Name/refer to a particular feature when talking/writing/searching about it.

1: Yes, very useful to have names for things!

2: I’m unsure. The extension names work quite well. But if this would be come an actively supported use-case (rather than an accidential one), should we come up with names for existing things as well? (-XWhereBindings). It doens’t seem to be a good idea to couple “well- identified feature with a clear name” and “compiler flag”

...
6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax)

Again similar to 2. I don’t see anything wrong with GHC just accepting unicode syntax when it encounters them, just like it accepts non-ASCII variable names.

(This is independent of whether GHC should print syntax in Unicode style unless asked to do it, but that’s not a language design question.)

...
7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with.

1: Yes, useful.

2: Possibly, but that would require a more defined story about backwards compatibility within an extension. Can we change extensions? Or only those that are somehow labeled to be more stable?

2Y: It could help if “being in GHC20xx” is used as a proxy for “kinda stable”, which is a prerequisite for this signallingto work reliably.

2N: That said, I don’t see much benefit of using this indirect compat signalling over just stating in the library which GHC versions it is known to work with, just like we do with library dependencies.

...
8. Retain access to deprecated features to smooth out migration over the deprecation period.

1: Yes, useful. Similar to question 3

2: Yes 2Y: Yes, by using an older GHC20xx one pins an older feature set, possibly including deprecated versions. This decouples “upgrading GHC” and “adopting the code base to the new dialect”, which should make life easier for developers.

...
9. Retain access to deprecated features indefinitely.

1: Unsure. Depends on how commonly used it is, and how expensive it is to carry around.

...
10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example)

1: I’m leaning to say no. Haskell + StrictData is a different language, and one that we can’t envision to be the default (I’d say). That use case should ideally be addressed in a different way that is a language extension, not a language change.

2: No 2N: Annotations maybe, or a new keyword?

...
11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too)

1: Strong yes. Barring ourselves from making changes that may affect some existing programs is no longer avoiding success at all costs.

2: Yes 2Y: Yes, definitely: It means that the programmer is in control when to apply a change like OverloadedStrings which may require some code changes.

...
12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it)

1: Yes.

2: No, a dedicated pragma would probably be cleaner, but willing to entertain that single odd case.

It would also be more consistent to always _parse_ the TH syntax (to avoid breakage when it is enabled, and to make reading code less ambiguous), and simply fail if the pragma is not set given.

...
13. CPP (this one is very unique isn't it?)

1: Yes 2: Again, dedicated pragma might be cleaner. Also helps programs parsing Haskell programs if the information is _always_ local in the file.

Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

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

Eric Seidel

22 Apr 22 Apr

1:09 p.m.

On Wed, Apr 19, 2023, at 08:20, Arnaud Spiwack wrote:

...

1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability)

I think this is a valid use case for extensions. I don't see a connection with GHC20xx and I think that's good -- GHC20xx is supposed to be about stable features.

...

2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language) 3. Restrict the use of novel features since the last established standard/report. 4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters) 6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax)

(I don't see a useful distinction between these categories, answering all together.) Yes, GHC (or at least the broader ecosystem) should support these use-cases. I think they might be better served by linters or warnings, but the features are complex enough that it may make sense to bundle the lints with GHC rather than defer to external tools.

...

5. Name/refer to a particular feature when talking/writing/searching about it.

No, this is not a valid use case. The Haskell Standard and the GHC User Guide can name features without introducing a formal extension for them. Algebraic Data Types and Lambdas are two examples of core named language features that do not have associated extensions.

...

7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with.

No, this is not a valid use case. We already have metadata in Cabal files to indicate GHC compatibility.

...

8. Retain access to deprecated features to smooth out migration over the deprecation period. 9. Retain access to deprecated features indefinitely.

(Again, same use-case.) No, these are not valid use-cases. We have existing deprecation mechanisms that should be preferred here. (And there's no such thing as an indefinite deprecation period. That would mean you're still supporting the feature.)

...

10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example) 11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too) 12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it) 13. CPP (this one is very unique isn't it?)

(This might be more controversial, but I think these are also all the same use-case, which I would dub "Change the language in a way that will never become the default".) Yes, these are valid use-cases. But, many existing cases of this use targeted pragmas (e.g. OVERLAPPING) rather than module-level extensions. I think both should be allowed, but the targeted version is preferred unless you really do want to change the behavior module-wide.

Simon Peyton Jones

26 Apr 26 Apr

8:23 a.m.

...

In this next round, I want us to give our opinion, on each of these use-cases, on whether we believe that this use-case is best served by extension. My goal, in this round, is not necessarily to build consensus for a policy, but to discover where there is consensus, and where there is controversy, so that we can discuss the relevant use-cases in more detail.

I went down the list and in every case I thought "yes, language extensions allow a user to do this, if they want". I struggled to answer your questions. Eg - X1 is this a use-case GHC should support. Well it already supports it. I suppose we could debate which are active goals and which are accidental, but before burning the midnight oil on that debate I'd love to know where this is going. - X2 is this use case best served by extensions. When you say "best served" you imply that, in each case, there is a well-defined alternative or alternatives that could be better. But I don't know what are the alternatives that we should be comparing with. - X3 Does GHC20xx help? What do you mean by "GHC20xx". I think you mean "The occasional release of a new flag, GHC2025, say, that implies a bunch of others. That seems a rather different debate, but in general I think the idea is a good one, if not done too frequently I feel as if I'm not being very helpful, which probably means I'm missing the point somehow! Simon On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack wrote:

...

Dear all,

In Round 1', we have gathered no less than 13 use-cases (see below) found in the community for Haskellers to motivate the need for extensions. Some of these use-cases are specific to a pretty definite list of extensions, some are not. Some extensions fall squarely in one use-case, some don't. Use-cases are not a classification of extensions, they're a classification of justifications for extensions to exist. Surely we've missed some, but it's alright to not be fully exhaustive.

In this next round, I want us to give our opinion, on each of these use-cases, on whether we believe that this use-case is best served by extension. My goal, in this round, is not necessarily to build consensus for a policy, but to discover where there is consensus, and where there is controversy, so that we can discuss the relevant use-cases in more detail.

In this round, I'm asking you, for each X∈{1,…,13}, to answer the following questions:

X.1: do you believe that this a use-case that GHC should support? (yes/no) X.2: regardless of your answer in X.1, if GHC supports this use-case, do you believe that this use-case is best served by extensions. (yes/no) X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) X.2.N: if you've answered “no” to X.2: what mechanism would you rather see supporting this use-case (free form)

I'll be on holiday next week, and will tally the results on the first week on May.

The 13 use-cases are

1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability) 2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language) 3. Restrict the use of novel features since the last established standard/report. 4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters) 5. Name/refer to a particular feature when talking/writing/searching about it. 6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax) 7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with. 8. Retain access to deprecated features to smooth out migration over the deprecation period. 9. Retain access to deprecated features indefinitely. 10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example) 11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too) 12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it) 13. CPP (this one is very unique isn't it?) _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Chris Dornan

9:32 a.m.

I agree with Simon. These all seem entirely reasonable ways of using the compiler to me. Chris

...

On 26 Apr 2023, at 13:23, Simon Peyton Jones wrote:

...
In this next round, I want us to give our opinion, on each of these use-cases, on whether we believe that this use-case is best served by extension. My goal, in this round, is not necessarily to build consensus for a policy, but to discover where there is consensus, and where there is controversy, so that we can discuss the relevant use-cases in more detail.

I went down the list and in every case I thought "yes, language extensions allow a user to do this, if they want". I struggled to answer your questions. Eg X1 is this a use-case GHC should support. Well it already supports it. I suppose we could debate which are active goals and which are accidental, but before burning the midnight oil on that debate I'd love to know where this is going. X2 is this use case best served by extensions. When you say "best served" you imply that, in each case, there is a well-defined alternative or alternatives that could be better. But I don't know what are the alternatives that we should be comparing with. X3 Does GHC20xx help? What do you mean by "GHC20xx". I think you mean "The occasional release of a new flag, GHC2025, say, that implies a bunch of others. That seems a rather different debate, but in general I think the idea is a good one, if not done too frequently I feel as if I'm not being very helpful, which probably means I'm missing the point somehow!

Simon

On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack mailto:arnaud.spiwack@tweag.io> wrote:

...
Dear all,

In Round 1', we have gathered no less than 13 use-cases (see below) found in the community for Haskellers to motivate the need for extensions. Some of these use-cases are specific to a pretty definite list of extensions, some are not. Some extensions fall squarely in one use-case, some don't. Use-cases are not a classification of extensions, they're a classification of justifications for extensions to exist. Surely we've missed some, but it's alright to not be fully exhaustive.

In this next round, I want us to give our opinion, on each of these use-cases, on whether we believe that this use-case is best served by extension. My goal, in this round, is not necessarily to build consensus for a policy, but to discover where there is consensus, and where there is controversy, so that we can discuss the relevant use-cases in more detail.

In this round, I'm asking you, for each X∈{1,…,13}, to answer the following questions:

X.1: do you believe that this a use-case that GHC should support? (yes/no) X.2: regardless of your answer in X.1, if GHC supports this use-case, do you believe that this use-case is best served by extensions. (yes/no) X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) X.2.N: if you've answered “no” to X.2: what mechanism would you rather see supporting this use-case (free form)

I'll be on holiday next week, and will tally the results on the first week on May.

The 13 use-cases are

1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability) 2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language) 3. Restrict the use of novel features since the last established standard/report. 4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters) 5. Name/refer to a particular feature when talking/writing/searching about it. 6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax) 7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with. 8. Retain access to deprecated features to smooth out migration over the deprecation period. 9. Retain access to deprecated features indefinitely. 10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example) 11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too) 12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it) 13. CPP (this one is very unique isn't it?) _______________________________________________ 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

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

Adam Gundry

4:21 p.m.

On 26/04/2023 13:23, Simon Peyton Jones wrote:

...

I went down the list and in every case I thought "yes, language extensions allow a user to do this, if they want". I struggled to answer your questions. Eg

* X1 is this a use-case GHC should support. Well it already supports it. I suppose we could debate which are active goals and which are accidental, but before burning the midnight oil on that debate I'd love to know where this is going.

I understand Arnaud's intention here to be that we debate what the purpose and goals of the extensions system should be. This might include saying that GHC shouldn't try to support certain use cases, or that for some use-cases we don't believe extensions are the right mechanism to use. My basic position is that it is crucial for extensions to be well-defined and introduce orthogonal language features. This isn't something GHC has always been good at historically, as a few extensions have accreted multiple somewhat-related effects. But given that caveat, I'm generally in favour of keeping many extensions (including splitting up extensions into small simple parts where appropriate). If users are intimidated by long extension lists, the solution IMHO is to create groups of related extensions, enable them by default (as in GHC20xx), and document them accordingly. With that in mind, here are my (tentative) answers... On 19/04/2023 13:20, Arnaud Spiwack wrote:

...

X.1: do you believe that this a use-case that GHC should support? (yes/no) X.2: regardless of your answer in X.1, if GHC supports this use-case, do you believe that this use-case is best served by extensions. (yes/no) X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) X.2.N: if you've answered “no” to X.2: what mechanism would you rather see supporting this use-case (free form)

...

1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability)

1.1: Yes 1.2: Yes 1.2.Y: Yes (GHC20xx can be used as a baseline, thereby making clear which extensions are more experimental and avoiding the need to list the non-experimental ones)

...

2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language)

2.1: Yes 2.2: Yes 2.2.Y: Yes In my view, it's not the fact of features being more complex that is crucial; rather the point is to have a language that is built up as a composition of pieces that can be understood (and enabled) independently.

...

3. Restrict the use of novel features since the last established standard/report.

3.1: Yes 3.2: Yes 3.2.Y: No I think it would be a shame to drop support for Haskell98/Haskell2010 unless there is a clear cost to maintaining such support.

...

4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters)

4.1: No 4.2: No 4.2.N: Merely disliking a feature isn't a good reason to make an extension out of it; using the warnings system is better, or moving a check to an external linter. Though of course controversial features may be extensions for other reasons.

...

5. Name/refer to a particular feature when talking/writing/searching about it.

5.1: Yes 5.2: No 5.2.N: We should strive to use consistent terminology and document feature names clearly, but that doesn't by itself require an extension.

...

6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax)

I (sorry, belatedly) think at least one use case should cover tools "outside the GHC ecosystem" rather than the "Haskell ecosystem"; in particular we should keep in mind the needs of other Haskell compilers and tools. On that basis: 6.1: Yes 6.2: Yes 6.2.Y: Yes

...

7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with.

7.1: No 7.2: No 7.2.N: The fundamental issue here is that GHC doesn't maintain stable meanings for extensions over time (and it doesn't seem feasible to do so). Thus I think it would be better if libraries communicate supported GHC versions in their cabal files, and the cabal solver used that information directly rather than relying on the other-extensions field.

...

8. Retain access to deprecated features to smooth out migration over the deprecation period. 9. Retain access to deprecated features indefinitely.

{8,9}.1: Yes {8,9}.2: Yes (where the feature being deprecated is an existing language extension or one can be sensibly defined retrospectively, as with DeepSubsumption) {8,9}.2.Y: Yes I see the question of whether deprecated features are available only for a migration period or indefinitely as orthogonal to whether they are extensions. Instead it depends on the specific case (how widely used is it, how easy is the migration path, how expensive is it to continue support). I think it's reasonable to have a feature deprecated indefinitely (because we advise against its use for new code, but it doesn't hurt to keep it around for backwards compatibility).

...

10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example) 11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too)

I don't see a clear distinction between these categories. Is it that 10 covers changes that will never be on by default, whereas 11 covers changes that we want to become the default but need a migration path? {10,11}.1: Yes {10,11}.2: Yes {10,11}.2.Y: Yes

...

12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it)

12.1: Yes 12.2: No 12.2.N: Controls over (compile-time?) performance should be expressed as `-f...` flags (but of course TemplateHaskell is an extension for other reasons).

...

13. CPP (this one is very unique isn't it?)

13.1: Yes 13.2: Yes (perhaps if we were to start again this could be its own pragma, but there's no point changing it now) 13.2.Y: N/A -- 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

27 Apr 27 Apr

3:34 a.m.

This is interesting. I find myself answering "no" to "do you believe this use-case is best served by extensions" for almost all use-cases, the only exception being for experimental/unstable language features and language features with a performance impact. Everything else can be served by either GHC20xx or warnings. Yes that means being less fine-grained in some cases, but that might be a good tradeoff between flexibility for users and complexity in the compiler - fewer combinations of extensions to consider would simplify things and leave less room for bugs. Answers below: On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack wrote:

...

X.1: do you believe that this a use-case that GHC should support? (yes/no) X.2: regardless of your answer in X.1, if GHC supports this use-case, do you believe that this use-case is best served by extensions. (yes/no) X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) X.2.N: if you've answered “no” to X.2: what mechanism would you rather see supporting this use-case (free form)

The 13 use-cases are

1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability)

1. yes 2. yes 2.Y no

...

2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language)

1. yes 2. no 2.N warnings, -Werror=feature

...

3. Restrict the use of novel features since the last established standard/report.

1. yes 2. no 2.N -XHaskell2010 and/or warnings

...

4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters)

1. yes 2. no 2.N warnings

...

5. Name/refer to a particular feature when talking/writing/searching about it.

1. yes 2. no - we don't need to support extensions to be able to name language features. 2.N continue to use the names we have now, but without supporting -XFoo for all extensions

...

6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax)

1. yes 2. no 2.N warnings

...

7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with.

1. yes 2. no 2.N GHC20xx

...

8. Retain access to deprecated features to smooth out migration over the deprecation period.

1. yes 2.no 2.N GHC20xx

...

9. Retain access to deprecated features indefinitely.

1. no

...

10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example)

1. yes 2. no 2.N GHC20xx

...

11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too)

1. yes 2. no 2.N GHC20xx

...

12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it)

1. yes 2. yes 2.Y no

...

13. CPP (this one is very unique isn't it?)

1. yes 2. no 2.N it should probably be a flag

...

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

Simon Peyton Jones

4:09 a.m.

...

Everything else can be served by either GHC20xx or warnings.

Let's unpack that statement a bit. I think GHC20xx is a bit of a red herring ... it doesn't change rapidly enough, and there will always be people who want a different combination. The thing about warnings is different. I think you are suggesting that we should: - Remove (say) MultiParamTypeClasses as an extension - Accept programs that use MultiParamTypeClasses unconditionally - But with a warning - That can be suppressed with -fno-warn-multi-param-type-classes So a long {-# LANGUAGE X1, X2 #-} preamble will be replace with a long {-# OPTIONS_GHC -fno-warn-X1 -fno-warn-X2 #-} block. Is that what you meant by "everything else best served by warnings"? I think that is a consistent position for extensions that use new syntax. But - Not all extensions use new syntax (e.g. -XPolyKinds). - You say "the only exception being for experimental/unstable language features and language features with a performance impact", but - if an experimental/unstable feature uses new syntax, it would again be fine with "Warning: you are using an experimental feature" - Ditto features that use new syntax with a perf impact - what about RebindableSyntax or Strict, which change semantics but add no new syntax? - It's not clear to me that saying `OPTIONS_GHC -no-warn-X1` is superior to `LANGUAGE X1`. In fact I mildly prefer the latter - It'd be a big upheaval to get from where we are, to get there But it is a consistent position. Are you advocating that change? Simon On Thu, 27 Apr 2023 at 08:35, Simon Marlow wrote:

...

This is interesting. I find myself answering "no" to "do you believe this use-case is best served by extensions" for almost all use-cases, the only exception being for experimental/unstable language features and language features with a performance impact. Everything else can be served by either GHC20xx or warnings. Yes that means being less fine-grained in some cases, but that might be a good tradeoff between flexibility for users and complexity in the compiler - fewer combinations of extensions to consider would simplify things and leave less room for bugs.

Answers below:

On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack wrote:

...
X.1: do you believe that this a use-case that GHC should support? (yes/no) X.2: regardless of your answer in X.1, if GHC supports this use-case, do you believe that this use-case is best served by extensions. (yes/no) X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) X.2.N: if you've answered “no” to X.2: what mechanism would you rather see supporting this use-case (free form)

The 13 use-cases are

1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability)

1. yes 2. yes 2.Y no

...
2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language)

1. yes 2. no 2.N warnings, -Werror=feature

...
3. Restrict the use of novel features since the last established standard/report.

1. yes 2. no 2.N -XHaskell2010 and/or warnings

...
4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters)

1. yes 2. no 2.N warnings

...
5. Name/refer to a particular feature when talking/writing/searching about it.

1. yes 2. no - we don't need to support extensions to be able to name language features. 2.N continue to use the names we have now, but without supporting -XFoo for all extensions

...
6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax)

1. yes 2. no 2.N warnings

...
7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with.

1. yes 2. no 2.N GHC20xx

...
8. Retain access to deprecated features to smooth out migration over the deprecation period.

1. yes 2.no 2.N GHC20xx

...
9. Retain access to deprecated features indefinitely.

1. no

...
10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example)

1. yes 2. no 2.N GHC20xx

...
11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too)

1. yes 2. no 2.N GHC20xx

...
12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it)

1. yes 2. yes 2.Y no

...
13. CPP (this one is very unique isn't it?)

1. yes 2. no 2.N it should probably be a flag

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

Eric Seidel

10:11 a.m.

On Thu, Apr 27, 2023, at 04:09, Simon Peyton Jones wrote:

...

The thing about warnings is different. I think you are suggesting that we should: • Remove (say) MultiParamTypeClasses as an extension • Accept programs that use MultiParamTypeClasses unconditionally • But with a warning • That can be suppressed with -fno-warn-multi-param-type-classes So a long {-# LANGUAGE X1, X2 #-} preamble will be replace with a long {-# OPTIONS_GHC -fno-warn-X1 -fno-warn-X2 #-} block.

I can't speak for Simon, but I felt similarly about Extensions vs Warnings. What you're saying here is not quite what I had in mind. For me it's more like

...

• Remove (say) MultiParamTypeClasses as an extension • Accept programs that use MultiParamTypeClasses unconditionally • If you want to disallow MPTCs, you can disable them with `-Wmulti-param-type-classes -Werror`

In other words, MPTCs are simply part of the language now. Not a second class citizen that must be opted into with an Extension or by *disabling* a Warning. We leave an escape hatch in the form of an opt-in warning for those who would rather not use MPTCs, much like other aspects of the language the may be controversial.

Adam Gundry

11:40 a.m.

On 27/04/2023 15:11, Eric Seidel wrote:

...

I can't speak for Simon, but I felt similarly about Extensions vs Warnings. What you're saying here is not quite what I had in mind. For me it's more like

...
• Remove (say) MultiParamTypeClasses as an extension • Accept programs that use MultiParamTypeClasses unconditionally • If you want to disallow MPTCs, you can disable them with `-Wmulti-param-type-classes -Werror`

In other words, MPTCs are simply part of the language now. Not a second class citizen that must be opted into with an Extension or by *disabling* a Warning. We leave an escape hatch in the form of an opt-in warning for those who would rather not use MPTCs, much like other aspects of the language the may be controversial.

Here's what I don't quite understand: MultiParamTypeClasses is already part of GHC2021 and thus enabled by default (unless the program is specifying e.g. Haskell2010 as the default-language). Given that, why is it worthwhile to go through the churn of replacing `-XNoMultiParamTypeClasses` with `-Werror=multi-param-type-classes`? If the issue is implementation complexity, then I don't see how changing one flag to another really helps that; to fundamentally simplify the implementation you have to eliminate the ability to disable the feature altogether. (And I would argue that the way to keep the implementation simple is to design language features that are orthogonal, rather than having one big monolithic language that can't be decomposed...) If it's a conceptual/documentation issue, could we instead rewrite the user's guide so that it assumes GHC2021 as a baseline, and presents multi-parameter type classes as a feature of "GHC Haskell" (with a side note that they can be disabled with NoMultiParamTypeClasses)? I'm sure I'm missing something... :-) Adam -- 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

Eric Seidel

6:49 p.m.

On Thu, Apr 27, 2023, at 11:40, Adam Gundry wrote:

...

Here's what I don't quite understand: MultiParamTypeClasses is already part of GHC2021 and thus enabled by default (unless the program is specifying e.g. Haskell2010 as the default-language). Given that, why is it worthwhile to go through the churn of replacing `-XNoMultiParamTypeClasses` with `-Werror=multi-param-type-classes`?

It may not be, but that's not the question we're trying to answer right now, at least not as I understood it. Arnaud asked us whether these are valid use cases for extensions. That's a "what should be" question. My answer is that restricting to a subset of the language should be done via warnings or linters, rather than via extensions. That's not the current pattern in GHC, but it's what I would do if we were starting over. Once we've established "what should be", we can then discuss "what to do about it", i.e. should we undertake a large refactoring of GHC to migrate all of these extensions to warnings? We might decide that it's worthwhile because of some reduction in code complexity. Or we might decide that it's not worthwhile because of the churn it would cause. But either way we have learned something about language design that can guide future decisions.

Simon Marlow

28 Apr 28 Apr

4:17 a.m.

Good! I'm glad we're discussing where this alternative design leads. I'm not sure whether I'm 100% advocating for it - it may be that ultimately it's not enough of an improvement over extension flags to warrant the churn. But I think it's worthwhile to explore it. (to be clear I don't think the idea of using warnings was mine, I forgot who originally suggested it but it came out of the discussion on the GDoc we had earlier) On Thu, 27 Apr 2023 at 09:07, Simon Peyton Jones < simon.peytonjones@gmail.com> wrote:

...

...
Everything else can be served by either GHC20xx or warnings.

Let's unpack that statement a bit. I think GHC20xx is a bit of a red herring ... it doesn't change rapidly enough, and there will always be people who want a different combination.

The thing about warnings is different. I think you are suggesting that we should:

- Remove (say) MultiParamTypeClasses as an extension - Accept programs that use MultiParamTypeClasses unconditionally

Only with GHC2021 and later

...

- But with a warning

which is disabled by default

...

- That can be suppressed with -fno-warn-multi-param-type-classes

maybe we call it -WMultiParamTypeClasses to keep the naming consistent. So

-Werror=MultiParamTypeClasses would be the way to disable it.

...

So a long {-# LANGUAGE X1, X2 #-} preamble will be replace with a long {-# OPTIONS_GHC -fno-warn-X1 -fno-warn-X2 #-} block.

No, most use cases would be using `{-# LANGUAGE GHC2021 #-}` or whatever. Use cases that wanted to use GHC2021 but disable specific extensions would need a `{-# LANGUAGE -Werror=whatever #-}` or the equivalent in the .cabal file.

...

I think that is a consistent position for extensions that use new syntax. But

- Not all extensions use new syntax (e.g. -XPolyKinds).

Sure, so if you want to disable PolyKinds then you must use a GHC20xx

version that doesn't include it. This is of course less flexible than what we currently have. But it might be advantageous: - We don't have to consider what happens when you turn off PolyKinds in combination with all the other extensions, and make all those combinations behave in some well-defined way (or, disallow certain combinations with an error when the combination doesn't make sense). We know that PolyKinds is only enabled along with all the other extensions in GHC2024 or whatever. Note that other languages do similar things: you can't turn off individual extensions in C++17 for example. - We're massively reducing the space of language variants to a set of a few language versions that we have carefully curated. That is, I postulate, a very good thing for most users and for the language in general.

...

- You say "the only exception being for experimental/unstable language features and language features with a performance impact", but - if an experimental/unstable feature uses new syntax, it would again be fine with "Warning: you are using an experimental feature"

We could only do that for things with genuinely new syntax (not stolen syntax!). So e.g. OverloadedLists couldn't be a warning, it has to be an experimental extension.

...

- Ditto features that use new syntax with a perf impact - what about RebindableSyntax or Strict, which change semantics but add no new syntax?

Both of those cases should arguably be flags instead of language

extensions. `{-# LANGUAGE -frebindable-syntax #-}`.

...

- - It's not clear to me that saying `OPTIONS_GHC -no-warn-X1` is superior to `LANGUAGE X1`. In fact I mildly prefer the latter - It'd be a big upheaval to get from where we are, to get there

Indeed!

...

But it is a consistent position. Are you advocating that change?

I'm not sure, but as I said at the top, I think it's worth exploring. Cheers Simon

...

Simon

On Thu, 27 Apr 2023 at 08:35, Simon Marlow wrote:

...
This is interesting. I find myself answering "no" to "do you believe this use-case is best served by extensions" for almost all use-cases, the only exception being for experimental/unstable language features and language features with a performance impact. Everything else can be served by either GHC20xx or warnings. Yes that means being less fine-grained in some cases, but that might be a good tradeoff between flexibility for users and complexity in the compiler - fewer combinations of extensions to consider would simplify things and leave less room for bugs.

Answers below:

On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack wrote:

...
X.1: do you believe that this a use-case that GHC should support? (yes/no) X.2: regardless of your answer in X.1, if GHC supports this use-case, do you believe that this use-case is best served by extensions. (yes/no) X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) X.2.N: if you've answered “no” to X.2: what mechanism would you rather see supporting this use-case (free form)

The 13 use-cases are

1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability)

1. yes 2. yes 2.Y no

...
2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language)

1. yes 2. no 2.N warnings, -Werror=feature

...
3. Restrict the use of novel features since the last established standard/report.

1. yes 2. no 2.N -XHaskell2010 and/or warnings

...
4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters)

1. yes 2. no 2.N warnings

...
5. Name/refer to a particular feature when talking/writing/searching about it.

1. yes 2. no - we don't need to support extensions to be able to name language features. 2.N continue to use the names we have now, but without supporting -XFoo for all extensions

...
6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax)

1. yes 2. no 2.N warnings

...
7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with.

1. yes 2. no 2.N GHC20xx

...
8. Retain access to deprecated features to smooth out migration over the deprecation period.

1. yes 2.no 2.N GHC20xx

...
9. Retain access to deprecated features indefinitely.

1. no

...
10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example)

1. yes 2. no 2.N GHC20xx

...
11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too)

1. yes 2. no 2.N GHC20xx

...
12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it)

1. yes 2. yes 2.Y no

...
13. CPP (this one is very unique isn't it?)

1. yes 2. no 2.N it should probably be a flag

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

Joachim Breitner

7:20 a.m.

Hi, Am Freitag, dem 28.04.2023 um 09:17 +0100 schrieb Simon Marlow:

...

Good! I'm glad we're discussing where this alternative design leads. I'm not sure whether I'm 100% advocating for it - it may be that ultimately it's not enough of an improvement over extension flags to warrant the churn. But I think it's worthwhile to explore it. (to be clear I don't think the idea of using warnings was mine, I forgot who originally suggested it but it came out of the discussion on the GDoc we had earlier)

I believe it was Richard’s. I also think this is a worthwhile discussion, even if the outcome would be that the design is desirable, but not worth the transition. What’s appealing about it is the pivot of perspective: No longer 2^n different Haskell-like languages, but rather one evolving Glorious Haskell, plus tools that help those who want to restrict themselves for whatever reason. Cheers, Joachim -- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/

Richard Eisenberg

30 Apr 30 Apr

10:05 p.m.

...

On Apr 28, 2023, at 7:20 AM, Joachim Breitner wrote:

I believe [the idea about using warnings] was Richard’s.

I indeed have been the one to advocate for this previously, and I still do. I think the current system of extensions presents a bewildering array of complexity to users, and (I claim) a big source of why people say Haskell is so complicated. Haskell, at its core, is beautifully simple! But this fact easily gets lost. So my goal in advocating using warnings is to try to reduce the number of language extensions. We would then have one big language, but users have ways of subsetting if they like. In some sense, this is just about marketing (it doesn't change expressiveness) but marketing is important. It would be easy to interpret existing -X flags as warning twiddles, so the idea is backward compatible. Richard

Adam Gundry

1 May 1 May

8:59 a.m.

Thanks, I think I'm beginning to understand the position more clearly now. I can see the argument that we should be more opinionated about presenting features as one of * recommended (part of the language, fairly stable); * experimental (not yet resolved one way or the other); or * discouraged (supported primarily for backwards compatibility). To some extent GHC2021 already acts as a recommendation, but there are still many extensions that it doesn't include, and it doesn't draw a line between "experimental" and "discouraged". So perhaps one path forward would be to try to expand the set of extensions in the next GHC20xx and at the same time try to be more explicit about "discouraged" extensions that are unlikely to make it into a future GHC20xx iteration? I'm worried, however, that there are in practice many "dialects" of Haskell and hence it may be difficult to establish consensus about how to categorise many extensions. GHC2021 is described in the user's guide as "stable and conservative". Should we instead aim for "stable and liberal", i.e. adding extensions when they are unlikely to change and are useful to some people, even if others dislike them? (For example, RecordWildCards might fit into this category.) That would move us towards "one big language", but I'm not yet wholly convinced that is desirable. After all it would make the "recommended" language bigger and more complicated, and potentially constrain future evolution in ways that are hard to predict now. I think all this is mostly separable from the mechanics of warnings vs LANGUAGE pragmas vs other compiler flags. The idea that we might replace `-XNoFoo` with `-Werror=foo` is (for me at least) a distraction from the main point. (Thus, concretely, I still argue we should accept #536.) Cheers, Adam On 01/05/2023 03:05, Richard Eisenberg wrote:

...

...
On Apr 28, 2023, at 7:20 AM, Joachim Breitner mailto:mail@joachim-breitner.de> wrote:

I believe [the idea about using warnings] was Richard’s.

I indeed have been the one to advocate for this previously, and I still do.

I think the current system of extensions presents a bewildering array of complexity to users, and (I claim) a big source of why people say Haskell is so complicated. Haskell, at its core, is beautifully simple! But this fact easily gets lost.

So my goal in advocating using warnings is to try to reduce the number of language extensions. We would then have one big language, but users have ways of subsetting if they like. In some sense, this is just about marketing (it doesn't change expressiveness) but marketing is important. It would be easy to interpret existing -X flags as warning twiddles, so the idea is backward compatible.

Richard

-- 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 Peyton Jones

2:18 p.m.

I'm in the "stable and liberal" camp. My general view is that we should offer extensions and let our users decide which ones they want to use. I can see the argument that we should be more opinionated about

...

presenting features as one of * recommended (part of the language, fairly stable); * experimental (not yet resolved one way or the other); or * discouraged (supported primarily for backwards compatibility).

I'd be fine with that. - I see the GHC20xx series as a way of codifying "recommended". - I'd add a category for "language variation" or something: things like -XStrict and -XRebindableSyntax which *change* rather than *extend* the language. Simon On Mon, 1 May 2023 at 13:59, Adam Gundry wrote:

...

Thanks, I think I'm beginning to understand the position more clearly now. I can see the argument that we should be more opinionated about presenting features as one of

* recommended (part of the language, fairly stable);

* experimental (not yet resolved one way or the other); or

* discouraged (supported primarily for backwards compatibility).

To some extent GHC2021 already acts as a recommendation, but there are still many extensions that it doesn't include, and it doesn't draw a line between "experimental" and "discouraged". So perhaps one path forward would be to try to expand the set of extensions in the next GHC20xx and at the same time try to be more explicit about "discouraged" extensions that are unlikely to make it into a future GHC20xx iteration?

I'm worried, however, that there are in practice many "dialects" of Haskell and hence it may be difficult to establish consensus about how to categorise many extensions.

GHC2021 is described in the user's guide as "stable and conservative". Should we instead aim for "stable and liberal", i.e. adding extensions when they are unlikely to change and are useful to some people, even if others dislike them? (For example, RecordWildCards might fit into this category.) That would move us towards "one big language", but I'm not yet wholly convinced that is desirable. After all it would make the "recommended" language bigger and more complicated, and potentially constrain future evolution in ways that are hard to predict now.

I think all this is mostly separable from the mechanics of warnings vs LANGUAGE pragmas vs other compiler flags. The idea that we might replace `-XNoFoo` with `-Werror=foo` is (for me at least) a distraction from the main point. (Thus, concretely, I still argue we should accept #536.)

Cheers,

Adam

On 01/05/2023 03:05, Richard Eisenberg wrote:

...
...
On Apr 28, 2023, at 7:20 AM, Joachim Breitner mailto:mail@joachim-breitner.de> wrote:

I believe [the idea about using warnings] was Richard’s.

I indeed have been the one to advocate for this previously, and I still

do.

...
I think the current system of extensions presents a bewildering array of complexity to users, and (I claim) a big source of why people say Haskell is so complicated. Haskell, at its core, is beautifully simple! But this fact easily gets lost.

So my goal in advocating using warnings is to try to reduce the number of language extensions. We would then have one big language, but users have ways of subsetting if they like. In some sense, this is just about marketing (it doesn't change expressiveness) but marketing is important. It would be easy to interpret existing -X flags as warning twiddles, so the idea is backward compatible.

Richard

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

Richard Eisenberg

8 May 8 May

7:59 a.m.

...

On May 1, 2023, at 8:59 AM, Adam Gundry wrote:

* recommended (part of the language, fairly stable);

* experimental (not yet resolved one way or the other); or

* discouraged (supported primarily for backwards compatibility).

Yes! And also Simon's addition of "language variation". My stance is (I claim) it is hard for users to navigate the current extension maze (e.g. it's pretty hard for someone to know that scary-sounding UndecidableInstances is safe to use in practice but that TypeFamilies may break their type inference, even if they never write a type family). We should strive to simplify this maze so that it's easier for our users to write effective Haskell. One way to phrase this is "stable and liberal". Richard

Arnaud Spiwack

6 Jul 6 Jul

5:03 a.m.

Dear all, A (very belated) thank you for the interesting conversation on this thread. I'm being very slow, but I'm still digesting the contents. I've tallied the answer on the questionnaire in this spreadsheet, that I've tried to make as helpful as possible (if only for my benefit, as I'm trying to make it speak) https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmeco... The rest of the conversation, I have yet to figure out what to do, but the discussion on classifying the extensions by stability seems to intersect very much with the recent proposal that has been submitted by the Haskell Foundation's Stability Working Group don't hesitate to check it out https://github.com/ghc-proposals/ghc-proposals/pull/601 . One thing I will say is that among the respondents, there appears to be a pretty clear consensus that extensions should not be forever. I'll probably make my next round about this (if things go right, later today; but I'm loath to make any promise, considering how late I've been on the previous rounds). /Arnaud On Mon, 8 May 2023 at 13:59, Richard Eisenberg wrote:

...

On May 1, 2023, at 8:59 AM, Adam Gundry wrote:

* recommended (part of the language, fairly stable);

* experimental (not yet resolved one way or the other); or

* discouraged (supported primarily for backwards compatibility).

Yes! And also Simon's addition of "language variation".

My stance is (I claim) it is hard for users to navigate the current extension maze (e.g. it's pretty hard for someone to know that scary-sounding UndecidableInstances is safe to use in practice but that TypeFamilies may break their type inference, even if they never write a type family). We should strive to simplify this maze so that it's easier for our users to write effective Haskell.

One way to phrase this is "stable and liberal".

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

Richard Eisenberg

30 Apr 30 Apr

9:56 p.m.

Thanks, Arnaud, for organizing this for us!

...

On Apr 19, 2023, at 8:20 AM, Arnaud Spiwack wrote:

X.1: do you believe that this a use-case that GHC should support? (yes/no)

I'm going to interpret "GHC" as "the Haskell toolchain". That is, I'll answer whether some official tool should support the use-case, but my answer to X.2.N may say that some other part of the ecosystem is better suited than GHC.

...

X.2: regardless of your answer in X.1, if GHC supports this use-case, do you believe that this use-case is best served by extensions. (yes/no) X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) X.2.N: if you've answered “no” to X.2: what mechanism would you rather see supporting this use-case (free form)

1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability)

1.1. Yes. 1.2. Yes 1.2.Y. Not really. Experimental extensions need to be fine-grained.

...

2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language)

2.1. Yes (but not in GHC itself) 2.2. No 2.2.N. This is better suited for non-GHC tools, such as a linter or an IDE. The fine-grained approach to extensions is not so helpful here.

...

3. Restrict the use of novel features since the last established standard/report.

3.1. No -- it's just too expensive to keep doing this 3.2. No 3.2.N. GHC could have a Haskell2010 mode that meets the standard, and then a normal mode that doesn't. There is no need for a slew of extensions.

...

4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters)

4.1. Yes (but not in GHC itself) 4.2. No 4.2.N. See 2.2.N. I don't see the difference between 2 and 4.

...

5. Name/refer to a particular feature when talking/writing/searching about it.

5.1. Yes 5.2. No 5.2.N. Careful documentation in the manual and consistent text in error messages.

...

6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax)

6.1. Yes 6.2. No 6.2.N. This sounds like a ./configure -time flag, if GHC is being built on a platform lacking some critical support. (Programmers may want to avoid using a non-universal feature, but that sounds more like 2 or 4 than this question.)

...

7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with.

7.1. Yes (but not in GHC itself) 7.2. No 7.2.N. This sounds like something a package installer should do. In some perfect world, a package could just name a set of features and then the tool finds a GHC that has those features, but GHC is just too complex in the real world -- people will just have to use version numbers.

...

8. Retain access to deprecated features to smooth out migration over the deprecation period.

8.1. Yes 8.2. Sometimes, yes 8.2.Y. No; this is essentially the dual to (1), and it wants a fine-grained approach 8.2.N. In some cases, this could be better achieved through warnings and other mechanisms. But sometimes a proper extension will be needed.

...

9. Retain access to deprecated features indefinitely.

9.1. No. If we're going to deprecate a feature, let's have the courage of our convictions. 9.2. Sometimes, yes 9.2.Y/N. Just like 8.2.Y/N.

...

10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example)

10.1. Yes, but very sparingly 10.2. No 10.2.N. These are not language *extensions*. These are language *alterations*. There should be a different mechanism. But, really, we should try very hard to avoid doing this, because it makes reading code much harder -- you can read and understand code only after looking at all of these settings. In practice, this might still end up fitting into the existing language-extensions framework, but I'd rather see a way of specifying these kinds of changes locally in a region of code, so that the choice is manifest in the source file.

...

11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too)

I can't see the difference between 11 and 10.

...

12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it)

12.1. Yes 12.2. Sure. 12.2.Y. No, because you want fine-grained control.

...

13. CPP (this one is very unique isn't it?)

13.1. Yes 13.2. No 13.2.N. This should be a compiler flag. It's not about the language really. Richard

...

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

684

Age (days ago)

762

Last active (days ago)

List overview

Download

19 comments

8 participants

participants (8)

Adam Gundry
Arnaud Spiwack
Chris Dornan
Eric Seidel
Joachim Breitner
Richard Eisenberg
Simon Marlow
Simon Peyton Jones

Language Extension Policy – Round 2

tags

participants (8)