[ghc-steering-committee] #380 GHC2021: How to proceed?

[Richard Eisenberg]

I'm in favor of keeping to the process -- and for keeping the discussion going. That is, we accept what we have on Tuesday. But we also use this experience to refine our criteria for GHC2021+n, depending on our chosen cadence. In particular, I think the discussion of whether extensions should be used to control language levels is very interesting, and I think we could get somewhere by continuing to work on this front.

There is one final step I would advocate for, beyond accepting the extensions we have on Tuesday: we should do a quick check that they form a reasonable set. For example, it would be very strange to allow e.g. TypeFamilies without MonoLocalBinds, or to allow DataKinds but not KindSignatures. I haven't double-checked for whether we meet this standard, but we should.

Thanks, Joachim, for steering this ship!
Richard

> On Dec 19, 2020, at 4:02 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> One other argument for allowing some more time for discussion: it's the holiday season and people are likely to be busy. I know Arnaud mentioned he would be completely offline for the next couple weeks.
> 
> Maybe it would make sense to timebox ourselves to the first or second week of January instead?
> 
>> On Dec 19, 2020, at 14:40, Joachim Breitner <mail at joachim-breitner.de> wrote:
>> 
>> Dear Committee, especially dear Simons,
>> 
>> when we originally outlined the process for determining what GHC2021
>> would be, we aimed for a four week period of discussion, at the end of
>> which we just go with whatever the ballots say.
>> 
>> That four week period would end next Tuesday.
>> 
>> Now, maybe unsurprisingly, there are many discussions going on, both
>> about concrete extensions and also meta-questions (e.g. should we use
>> GHC2021 to spread certain best practices? Can a certain class of users
>> expect to not have to turn on other extensions? Do we want to preserve
>> the property of some extensions as heralds for a certain kind or style
>> of code?).
>> 
>> This poses the question:
>> Should we stick to the process, give everyone a chance to revise their
>> votes, and call it a day on Tuesday?
>> Or would that just lead to foul compromises, and we should keep
>> debating until we have more clarity?
>> 
>> In favor of sticking to the process:
>> We expected that something like GHC2021 will cause lots and lots of
>> discussions, many of them related to opinions, and there will likely
>> never be a obvious, clear, definite consensus on what the “best”
>> GHC2021 is. That’s why we set out with a time limit, as picking _some_
>> GHC2021 (with plenty of obvious extensions safely in) with reasonable
>> effort is better than holding long and very time-consuming discussions
>> with diminishing returns. Also, there will be a later iteration to iron
>> out the wrinkles that we didn’t get to do this round.
>> 
>> In favor of continuing the discussion:
>> The discussion is fruitful and interesting. We (well, certainly I)
>> learned a fair bit about the various extensions. Also, discussing the
>> meta-questions and coming to an agreement there could help us produce a
>> more principled, consistent GHC2021, and maybe even help us understand
>> the various purposes and goals of the extensions mechanism beyond
>> GHC2021. And if, I mean when, we finish these discussions, we have
>> likely produced a “better” GHC2021.
>> 
>> 
>> Personally, I’m leaning towards time-boxing the discussion and
>> concluding the vote on Tuesday. That said, if the committee has energy
>> and motivation to continue debating, I’m certainly up for that (my next
>> two weeks will be relatively quiet, and I might enjoy diving into long
>> discussions – you’ve been warned).
>> 
>> I think it would be best if the chars make a judgment call as to how we
>> should proceed. Simon, Simon: How do you want us to proceed?
>> 
>> 
>> 
>> 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