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

To me accepting things on Tuesday feels quite premature. I actually don't even know what we'd be accepting. -Iavor On Sat, Dec 19, 2020 at 2:08 PM Richard Eisenberg wrote:

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 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 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@joachim-breitner.de http://www.joachim-breitner.de/

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org

https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee