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

[Arnaud Spiwack]

Dear all,

For this round, I'd like to build on the results of last round [1]. One
thing that strikes me in the results, bearing in mind that 6 out of 10
members answered the question directly, and that none of this is without
dissent anyway, is that there seems to be a general feeling that extension
should not stay forever.

What I'm reading is that most respondents seem to believe that when an
extension becomes part of GHC20xx, it should be removed (with a deprecation
period, I'd imagine): if you want the feature, use GHC20xx.

Now, before I explore this question further, I should acknowledge that this
doesn't directly help answering the questions that I set to resolve when
this all began. Namely, under what principles do we judge extensions (in
particular whether a proposal should be one of several extensions). But I
think it's likely to help. I'm starting with this conversation because it's
relatively concrete, probably less controversial than other questions, and
as such, I'm hoping that it'll help us discuss the more difficult questions
with a little more understanding of what we collectively believe.

Let's explore what it would mean for an extension to be removed.
- The extension wouldn't appear in `$ ghc --show-options` (currently `$ ghc
--show-options | grep '\-X'` has 268 lines, almost every extension accounts
for 2 lines)
- The programmer can't turn the extension on or off directly
- The documentation, in the user manual, of the corresponding feature would
be moved from the “Language extension” section to somewhere else (maybe a
new section “Language features”? Not sure what is natural here)
- Error messages about the feature not being activated would stop
suggesting you use the extension, but instead that you use one of the
appropriate GHC20xx.
- For some extension, we could provide a warning (off by default) to allow
those who want to avoid the corresponding to disallow it in their codebase.
But certainly not all extensions would be turned into warnings: I don't
anticipate anybody will want to specifically avoid -XBinaryLiteral for
instance.
- Am I forgetting something?

It doesn't mean that the extension must disappear in the implementation of
GHC: this is an implementation detail (maybe it'll be beneficial for some
extensions to be removed and other not, I don't feel capable of
anticipating this). But the extension would not be visible or accessible to
the user.

Now the question is: ignoring the question of whether we have time to
retroactively do this, does this look like this would be part of your ideal
vision for GHC. If not, please argue.

[1]
https://docs.google.com/spreadsheets/d/1cRTJ2go5opXjIp-kojR_eOA-RWNBq2jzmecoSfhnvuE/edit?usp=sharing

-- 
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/20230707/195f4dfe/attachment.html>