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

Fri Dec 2 17:27:05 UTC 2022

While I can see the value of expecting proposed extensions to finally be always on I am skeptical that we will be able to just force the community to accept that each extensions is going to be either binned or always on. It doesn’t, for me, fit with the history of Haskell and GHC being an open platform that encourages experimentation. 

(I don’t want to sideline the discussion by offering examples but I am sure we can all think of extensions in the gray zone that we like to break out on occasion or use extensively that would be contentious candidates for permanent enablement.)

I am sympathetic to the idea of a new language standard that we promote heavily and encourage developers, tools, tutorials and courseware to favour —if we get this right then we will reap the benefits of a strong standard. But if we take it upon ourselves to try and force an extension combination of our choosing on the community because we believe the community will benefit from a big reset then I think it could blow up on us really badly, with forks and factions which could be truly difficult to manage — and fatally discourage adoption.

Chris

> On 2 Dec 2022, at 16:43, Simon Marlow <marlowsd at gmail.com> wrote:
> 
> I also think I've been pretty vocal in the past about favouring the view that extensions should be on a path to being on by default - indeed in the language standard, if we ever have another one of those.
> 
> Taking this approach more literally than we do would lead to difficult choices. Choices that penalise sections of the community with particular preferences. However, *not* making those choices penalises the whole community, perhaps not as visibly: more choices leads to a greater cognitive load, a longer learning curve, a greater barrier to entry off of which many potential users will bounce. And for us compiler developers, more alternatives and combinations to consider and test for, with more surprising emergent behaviours, more bugs and more work to do.
> 
> In my view, if we want greater adoption we have to be opinionated: make difficult decisions that remove choices and streamline the language. At the very least, don't add more choices.
> 
> But to Joachim's specific question: yes I like the idea of considering the "when will it be ready?" question for each extension, to precompute the input to the GHC20xx process.
> 
> Cheers
> Simon
> 
> On Fri, 2 Dec 2022 at 15:06, Arnaud Spiwack <arnaud.spiwack at tweag.io <mailto: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 <mailto: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 <mailto:mail at joachim-breitner.de>
>   http://www.joachim-breitner.de/ <http://www.joachim-breitner.de/>
> 
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org <mailto:ghc-steering-committee at haskell.org>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <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/72d056b9/attachment-0001.html>