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

[Simon Peyton Jones]

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

I don't have a strong opinion myself either way.  But I am a little
concerned that if we decided to do it, we'd then have to pour energy into
implementation (admittedly not hard, just deleting extension-parsing code
and updating documentation) and publicity.  More controversially, zillions
of library authors would be forced to update their packages.  In pursuit of
what?  A compiler that can do slightly less than it could before the change.

So I'm a bit sceptical.  What would sway me is if our users consistently
said "yes!  Please remove those extensions in favour of GHC20xx".   The
question is concrete enough that we could survey our users, and I think we
probably should before doing this, even if there is a consensus among us.

Simon

On Fri, 7 Jul 2023 at 08:44, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> 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.
> _______________________________________________
> 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/20230707/6653bb99/attachment-0001.html>