<div dir="ltr"><div dir="ltr"><div>I believe that I've been vocal in the past about my view that extensions should eventually become on by default. And even about the fact that I struggle to understand the point of view of extensions as configuration switches. I have no idea, however, how numerous each side of this debate is, nor how strongly the beliefs are held (very strongly in my case, obviously, but I don't know for others).</div><div><br></div><div>I think that you're right, Joachim, and that it's time to make a definite decision about that and make the decision one of our Principles.</div><div><br></div><div>If we come to the side that extensions are to eventually become defaults, I agree that the question of how to deprecate extensions that will never make it to the default is something that we have to tackle. A slightly more difficult discussion is how do we deprecate things that used to be the default. Imagine, say, that we want to make `-XMonoLocalBinds` the default, `-XMonoLocalBinds` is really removing a feature (as such it should probably be named something like `-XNoGeneralizeLocaBinds`), what does the deprecation period look like? Maybe it's actually the same question as deprecating a non-default extension, but maybe not.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 2 Dec 2022 at 12:07, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Committee and Community,<br>
<br>
occasionally we have meta-discussions about GHC language extensions:<br>
Should they be allowed to be fork-like, where some extensions are<br>
unlikely to be used together and some stay opt-in forever? Or should<br>
(ideally) every extension be on track to become on-by-default.<br>
<br>
Of course there are a few “old” extensions that by their very nature<br>
are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the<br>
obvious candidates). Let’s put them aside for this discussion. I’d<br>
wager that if we’d introduce them these days, they wouldn’t be language<br>
extensions in the first place, but maybe modifiers on the module.<br>
<br>
I am mostly in the camp “every extension should be on track to become<br>
default (or be discarded)”. Once a language feature has been proven<br>
useful and reasonable stable, I see little value in requiring<br>
programmers to jump through hoops to use them.<br>
<br>
Is that the prevalent view here as well, or do we have a strong camp<br>
saying that our current “pick-and-choose” approach to language features<br>
is actually a good thing in its own (and not just a necessary<br>
nuisance)?<br>
<br>
If we assume the former, then maybe it would be worth to frame the<br>
discussion around new language extensions, and the discussion about<br>
which language extensions become default, around that vision.<br>
Concretely:<br>
<br>
* A new language proposal should not just be good enough for “worth <br>
building for those who explicitly turn it on”, but really ought<br>
convince as “this will make Haskell better for all” (and not just<br>
“a Haskell”).<br>
<br>
* Most new language features should probably not on by default <br>
initially, as usual, and are initially experimental. But then the<br>
proposal, and if accepted the documentation of the extension, should<br>
as explicit as possible explain why it is not yet default: What<br>
needs to happen for _this_ extension to be considered ready – or<br>
judged negatively and put on a track towards removal.<br>
<br>
This could be something like “been available for n releases, been<br>
stable for m releases”. (I wonder what other kind of criteria to<br>
expect here?)<br>
<br>
* The process for defining GHC20xx would then become very different:<br>
We’d go through all experimental extensions, check if the criteria<br>
are satisfied, maybe apply some common sense if the criteria are <br>
still good ones, and turn it on if so.<br>
<br>
This may turn the process to be more structured and maybe more<br>
predictable, and hopefully reduces the number of non-default extensions<br>
developers have to make a decision about (probably good).<br>
But it does raise the bar for new language features (is that good?).<br>
And, if applied consequently, it suggests to deprecate and eventually<br>
remove extensions that turn out to not be default-worthy after all<br>
(that’s kinda harsh)?<br>
<br>
As you can see I am a bit unsure about what the criteria are that we<br>
could put in the docs. Are they really different for different<br>
extensions? But the fact that its hard to come up right now with a<br>
concrete reason why extension X is not yet the default does point to a<br>
hole in our thinking and our process!<br>
<br>
And it is the same question that we face when discussing GHC20xx. So I<br>
guess what I am proposing here is: Have that discussion (when is it<br>
ready?) already when accepting a proposal, and document it in clear<br>
sight for our users, rather than have it over and over when debating<br>
GHC20xx.<br>
<br>
This is not a concrete (meta-)proposal, but hopefully tasty food for<br>
thought.<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
</div>