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

Mon Jul 17 08:52:58 UTC 2023

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/601>makes 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 <arnaud.spiwack at 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 <
> 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/00d1808b/attachment-0001.html>