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

[Joachim Breitner]

Hi,

thanks for your work of clearing the mist.

Am Donnerstag, dem 30.03.2023 um 11:03 +0200 schrieb Arnaud Spiwack:
> 1. Have we missed some use-cases, if so describe? (I'm sure we have,
>    so I'd be surprised if nothing turns up here)

Another reason, mostly for completeness, is

   X. Programmers use extensions to _refer_ to a particular feature
   when talking/writing/searching about it. They give names to concepts
   that might not have an obvious canonical name otherwise.

Imagine LambdaCase did not have that name; it would be slightly harder
to talk about it.

---

Since your point 1 has an explicit list of reasons why an extension is
no on by default (“experimental or unstable”, with the word “early”
signaling that this status is expected to change)

I wonder if we need more points for “Developer wants access to features
not on-by-default for some other reasons”. In fact, you list some more
reasons (4/5 – deprecated, 7 – not backward compatible, 8 – perf
impact), but the list seems incomplete.

For example RecordWildCards doesn’t seem to be experimental, unstable,
deprecated or perf impacting to me. Nor does UnicodeSyntax.

So it’s not clear to me if you meant to put them under 1 (and
“experimental and unstable” needs to be extended) or under extra
bullets.

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

And then the question of why an extension is not on by default
(present, past, future…) would be separate from that.

Cheers,
Joachim





-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/