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

[Arnaud Spiwack]

*@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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230710/5a5672d7/attachment.html>