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

[Arnaud Spiwack]

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

-- 
Arnaud Spiwack
Director, Research at https://moduscreate.com and https://tweag.io.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230717/acd21391/attachment.html>