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

[Simon Peyton Jones]

>
> 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 <arnaud.spiwack at 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 and https://tweag.io.
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230710/5c2aad22/attachment.html>