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

[Alejandro Serrano Mena]

My main wondering is whether we will in fact change anybody’s mind. For
example, I am happy to accept every extension we are discussing in Kialo,
but I am having a hard time writing more reasons why we should really get
ScopedTypeVariables in GHC2021.

According to the proposal, we would have some community input at this
point, right? Maybe it’s a good moment to announce that we have interim
results and that people can discuss in the proposal PR.

Alejandro

El El sáb, 19 dic 2020 a las 23:35, Iavor Diatchki <iavor.diatchki at gmail.com>
escribió:

> 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 <rae at richarde.dev>
> 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 <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
>>
>> _______________________________________________
>> 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/20201220/48988b1b/attachment.html>