Re: [ghc-steering-committee] Language Extension Policy – Round 2

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