[ghc-steering-committee] Language Extension Policy – Round 1'

[Arnaud Spiwack]

(sorry, it's been a busy week, next email thread comes out today, or
tomorrow at the latest)

Joachim:

> From a user-point of view, it seems you could possible merge 1, 4, 5,
> 6, 7 and 8 as “Developer wants access to features not on by default”.
> The developer probably doesn’t really care _why_ the extension is not
> on by default, they just want to use it when they want to use it :).
>

At the end of the day, an extension is either a feature that is off by
default and can be turned on, or on by default and can be turned off. I
don't think we've said much when we've reduced the users' behaviour to that
level. So I wanted this list to be specifically about the why. And I think
the users do care. GHC Proposals say “I want a new extension to support X”,
I wanted to be as exhaustive as possible to then be able to try and then
delineate the X-s that we intend language extensions to support.

On Fri, 7 Apr 2023 at 17:33, Chris Dornan <chris at chrisdornan.com> wrote:

> As Joachim says, "Programmers use extensions to _refer_ to a particular
> feature  when talking/writing/searching about it."
>
> I think this is generally important. The language reports provide the
> foundations for understanding the language and it is important to have a
> handle to describe the various departures from it -- at least until a new
> report around which near universal acceptance can be established.
>
> I would extend "2. Restrict the use of more complex features" to say "2.
> Restrict the use of _novel_ and more complex features".  I think many just
> want to say exactly how they are departing from Haskell 2010, whether those
> deltas are complex or otherwise.
>
> Chris
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230417/88bc2837/attachment.html>