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

[Simon Peyton Jones]

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

I'm not sure we can make it completely black and white.

Punning is an example.  Some people Really Want to use punning (have a data
type and a data constructor with the same name). Others Really Do Not Want
punning because they want to do lots of dependently typed programing.  They
don't-want it so much that they want warnings if they accidentally use it.
(Simply refraining from punning is not enough for them.)

Neither group is wrong... it's simply a stylistic choice.  But if we
solidly adopt one choice or the other, we are privileging one group over the
other, which to me seems like risking unnecessary conflict, one that could
absorb precious cycles we could more profitably spend elsewhere.

Simon

On Fri, 2 Dec 2022 at 15:06, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> 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
>>
> _______________________________________________
> 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/d7df0268/attachment-0001.html>