[ghc-steering-committee] GHC2023

[Simon Peyton Jones]

Just to check: you are talking about this doc: Policy on language extensions
<https://docs.google.com/document/d/1_-hPh8BRhKNlzM0dC1IRSmjCqPym9mXx9NjC7jUlpRQ/edit?usp=sharing>

I agree that it would be sensible to sort this doc first.

Arnaud might be another possible driving force to getting it done?

Simon

On Wed, 11 Jan 2023 at 14:55, Simon Marlow <marlowsd at gmail.com> wrote:

> I was just perusing the doc and after a flurry of activity it seems to be
> stalled in various places. I doubt we'll make more progress without someone
> actively driving it to a conclusion - several of the threads just end up in
> minor differences of opinion and nobody feels enough ownership to resolve
> them with edits directly. Meanwhile, the comments on the doc are getting a
> bit unwieldy to work with.
>
> Still, I think it has been super useful so far - in particular the idea of
> using the warning system instead of turning off extensions is a really nice
> simplification.
>
> I personally have sporadic time to work on this but probably not enough to
> satisfactorily drive it. Richard, I'd be very happy if you wanted to take
> this on; alternatively we can continue via email as best we can.
>
> I think we should next
> 1. Resolve the categorisation (Richard's in section 2 vs. mine in 2.2)
> 2. Resolve the strategy (Simon's sec 3 vs. Joachim's sec 4)
>
> Cheers
> Simon
>
> On Wed, 11 Jan 2023 at 13:28, Richard Eisenberg <lists at richarde.dev>
> wrote:
>
>> I'd personally rather spend our collective energies on landing the
>> thoughts in our "Policy on Language Extensions" document. That is, work out
>> any remaining points of disagreement and then move the document into the
>> repo. In particular, if we end up in a place where we're content to add new
>> syntax-guarded features without a new extension flag, that will, in turn,
>> inform the GHC2023 idea.
>>
>> I don't have the bandwidth to both work on GHC's type-checker (as I'm
>> doing weekly, as Simon and I coordinate) and push such a thing through.
>> Though if no one else wants to land that document, I think it's worth my
>> slowing down type-checker work for a few weeks to do so. So any other
>> volunteers here? Sorry to redirect us from the immediate task at hand --
>> GHC2023 -- but one of my principles is that it's best to work out
>> principles (i.e. our policy on extensions) before specifics.
>>
>> Richard
>>
>> On Jan 11, 2023, at 4:29 AM, Arnaud Spiwack <arnaud.spiwack at tweag.io>
>> wrote:
>>
>> Empirically, I don't feel quite ready to make a call for GHC2023. So I
>> think that I'd favour a 3-year cadence.
>>
>> On Tue, 10 Jan 2023 at 11:44, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>>
>>> Hi,
>>>
>>> Am Dienstag, dem 10.01.2023 um 10:31 +0000 schrieb Simon Peyton Jones:
>>> >
>>> > It seems a very funny way to do it.  I'd prefer to ask "what cadence
>>> > do we want" and then move on to discuss features individually.  At
>>> > the moment I might think "yes, extension X belongs in the next
>>> > GHC20xx", so do I vote yes or no for X?
>>>
>>> Ah, I see the confusion. The question is _not_ about “the next
>>> GHC20xx”, but it is about “GHC2023”, i.e. what do we want to no. The
>>> answer may well be “no extension is pressing enough to make a release
>>> now”.
>>>
>>> A year ago we concluded to
>>>
>>> > don’t work on defining GHC2022, and the next update
>>> > will be GHC2023 (or later).
>>>
>>> and now we have to decide if it’s going to be GHC2023 or later.
>>>
>>> Maybe what I want to say is that by deciding whether we have GHC2023 or
>>> not, we are (implicitly) setting a precedence for what could become a
>>> regular cadence, should we not change our minds in the following years.
>>>
>>>
>>> > What do other members of the committee think about cadence?  RSVP!
>>> > You are a member!
>>>
>>> I’m also curious :-)
>>>
>>> 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/20230112/667eec2c/attachment-0001.html>