[ghc-steering-committee] Why not?, rather than, why?

Fri Dec 2 15:06:03 UTC 2022

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

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.

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.

On Fri, 2 Dec 2022 at 12:07, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> Hello Committee and Community,
>
> occasionally we have meta-discussions about GHC language extensions:
> Should they be allowed to be fork-like, where some extensions are
> unlikely to be used together and some stay opt-in forever? Or should
> (ideally) every extension be on track to become on-by-default.
>
> Of course there are a few “old” extensions that by their very nature
> are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the
> obvious candidates). Let’s put them aside for this discussion. I’d
> wager that if we’d introduce them these days, they wouldn’t be language
> extensions in the first place, but maybe modifiers on the module.
>
> I am mostly in the camp “every extension should be on track to become
> default (or be discarded)”. Once a language feature has been proven
> useful and reasonable stable, I see little value in requiring
> programmers to jump through hoops to use them.
>
> Is that the prevalent view here as well, or do we have a strong camp
> saying that our current “pick-and-choose” approach to language features
> is actually a good thing in its own (and not just a necessary
> nuisance)?
>
> If we assume the former, then maybe it would be worth to frame the
> discussion around new language extensions, and the discussion about
> which language extensions become default, around that vision.
> Concretely:
>
>  * A new language proposal should not just be good enough for “worth
>    building for those who explicitly turn it on”, but really ought
>    convince as “this will make Haskell better for all” (and not just
>    “a Haskell”).
>
>  * Most new language features should probably not on by default
>    initially, as usual, and are initially experimental. But then the
>    proposal, and if accepted the documentation of the extension, should
>    as explicit as possible explain why it is not yet default: What
>    needs to happen for _this_  extension to be considered ready – or
>    judged negatively and put on a track towards removal.
>
>    This could be something like “been available for n releases, been
>    stable for m releases”. (I wonder what other kind of criteria to
>    expect here?)
>
>  * The process for defining GHC20xx would then become very different:
>    We’d go through all experimental extensions, check if the criteria
>    are satisfied, maybe apply some common sense if the criteria are
>    still good ones, and turn it on if so.
>
> This may turn the process to be more structured and maybe more
> predictable, and hopefully reduces the number of non-default extensions
> developers have to make a decision about (probably good).
> But it does raise the bar for new language features (is that good?).
> And, if applied consequently, it suggests to deprecate and eventually
> remove extensions that turn out to not be default-worthy after all
> (that’s kinda harsh)?
>
> As you can see I am a bit unsure about what the criteria are that we
> could put in the docs. Are they really different for different
> extensions? But the fact that its hard to come up right now with a
> concrete reason why extension X is not yet the default does point to a
> hole in our thinking and our process!
>
> And it is the same question that we face when discussing GHC20xx. So I
> guess what I am proposing here is: Have that discussion (when is it
> ready?) already when accepting a proposal, and document it in clear
> sight for our users, rather than have it over and over when debating
> GHC20xx.
>
> This is not a concrete (meta-)proposal, but hopefully tasty food for
> thought.
>
> Cheers,
> Joachim
>
>
>
>
> --
> Joachim Breitner
>   mail at joachim-breitner.de
>   http://www.joachim-breitner.de/
>
> _______________________________________________
> 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/20221202/8bfce2af/attachment.html>