From simon.peytonjones at gmail.com Sun Nov 5 23:03:31 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Sun, 5 Nov 2023 23:03:31 +0000 Subject: [ghc-steering-committee] GHC stability discussions Message-ID: Dear GHC Steering Committee We have several threads about GHC's stability in progress: - Proposal 601: GHC extension life cycle . This introduces the notion of a "Stable" and "Experimental" extension. It was written by David C but has stalled now that he has stepped down as ED. - GHC Stability Goals , builds on #601 with general rules GR1-3. This is not a change to GHC (hence not a GHC proposal) more a clarification about how the GHC Steering Committee works. - Proposal 620: Extensions and warnings . This proposal keeps moving in the same direction, unifying warnings and extensions. - Proposal 617: add -experimental flag . This builds on #601 by providing an enforcement mechanism. It is strongly affected by #620. It would be good to get some of this decided. Too much is in the air at the moment! Personally I think: - We can agree at least the Stable/Experimental part of #601 - The Stability Goals seem fairly uncontroversial. Shall we just make it part of the GHC Proposal process documentation - #620 is new; your views would be welcome - The approach to #617 may depend on the outcome of #620. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Nov 6 08:56:56 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 06 Nov 2023 09:56:56 +0100 Subject: [ghc-steering-committee] GHC stability discussions In-Reply-To: References: Message-ID: Hi, Am Sonntag, dem 05.11.2023 um 23:03 +0000 schrieb Simon Peyton Jones: > It would be good to get some of this decided. Agreed! >   Too much is in the air at the moment!  Personally I think: >  * We can agree at least the Stable/Experimental part of #601 >  * The Stability Goals seem fairly uncontroversial.  Shall we just make it part of the GHC Proposal process documentation >  * #620 is new; your views would be welcome >  * The approach to #617 may depend on the outcome of #620. #601 has more categories than Stable/Experimental, and an enforcement mechanism, which seems to be subsumed by #617 and/or #620, is that right? Then maybe we can send #601 back to revision (or reject it), and just cherry-pick the ideas that we care about? The “Stability Goals” document is a bit more than just goals, it’s actually a pretty clear policy with rules that sound like fresh long distance hiking trails (GR…). But yes, we could ratify them and put them somewhere useful. But why not the GHC documentation? The guarantees written down there, and the definition of “stable package” are relevant to the users, not just those writing proposals. Agreed with parting #670 until #620 is done. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simon.peytonjones at gmail.com Mon Nov 6 09:09:44 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 6 Nov 2023 09:09:44 +0000 Subject: [ghc-steering-committee] GHC stability discussions In-Reply-To: References: Message-ID: > > Then maybe we can send #601 back to revision (or reject it), and > just cherry-pick the ideas that we care about? > Let's ask Trevis and Chris, the other two co-authors. There is significant interaction with #620. For example, #620 lets you warn on a use of GADTs, whereas #601 lets you warn simply about the presence of -XGADTs flag. (I am pretty doubtful about the utility of having both.) I am pretty keen on at least establishing a Stable/Experimental distinction. I'm agnostic about how many other categories, if any, to establish. The “Stability Goals” document is a bit more than just goals, it’s > actually a pretty clear policy.... But yes, we could ratify them and put > them somewhere useful. But why not the GHC documentation? > I advocate for incorporating them in the GHC Steering Committee process, not GHC documentation, because the rules GR1-3 primarily cover decisions of the GHC Steering Committee. That is, what changes do we accept? For example, we might be more willing to accept a breaking change to an Experimental feature than a Stable one. Simon On Mon, 6 Nov 2023 at 08:57, Joachim Breitner wrote: > Hi, > > Am Sonntag, dem 05.11.2023 um 23:03 +0000 schrieb Simon Peyton Jones: > > It would be good to get some of this decided. > > Agreed! > > > Too much is in the air at the moment! Personally I think: > > * We can agree at least the Stable/Experimental part of #601 > > * The Stability Goals seem fairly uncontroversial. Shall we just make > it part of the GHC Proposal process documentation > > * #620 is new; your views would be welcome > > * The approach to #617 may depend on the outcome of #620. > > #601 has more categories than Stable/Experimental, and an enforcement > mechanism, which seems to be subsumed by #617 and/or #620, is that > right? Then maybe we can send #601 back to revision (or reject it), and > just cherry-pick the ideas that we care about? > > The “Stability Goals” document is a bit more than just goals, it’s > actually a pretty clear policy with rules that sound like fresh long > distance hiking trails (GR…). But yes, we could ratify them and put > them somewhere useful. But why not the GHC documentation? The > guarantees written down there, and the definition of “stable package” > are relevant to the users, not just those writing proposals. > > Agreed with parting #670 until #620 is done. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Mon Nov 6 09:10:21 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Mon, 06 Nov 2023 10:10:21 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation Message-ID: Dear Committee, I’d like to get the committe involvement in GHC2024 started. The current proposal is at https://github.com/ghc-proposals/ghc-proposals/pull/613 https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst At the moment, six changes relative to CHC2021 are proposed by committee and by community members. See the proposal for rationales. My goal is to have a decision in time for 9.10. I suggest we use November to deliberate the proposals and maybe add more changes to the list, and then vote in early December. We’ll put each change separately on the ballot. I know that there are ongoing discussions that could arguably affect how we want the next GHC20xx to look like, in particular the just opened #620, and I anticipate a desire to postpone GHC2024 until that has been decided. But I recall that we postponed GHC2023 for (among other reasons) for the same reason, and I wouldn’t be surprised that if in a year we have yet another unresolved question that seems worth waiting for. If this pattern reminds you of the GHC release process before we introduced the regular cadence, then maybe you’ll agree that if we want a predictable and reasonable frequent stream of language editions, we have to avoid such delays when feasible. So please let us know what you think of the proposed changes, what other changes you want to see, or if you have qualms about the process. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Mon Nov 6 14:20:47 2023 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Mon, 6 Nov 2023 15:20:47 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: References: Message-ID: I've just pushed a bunch of extra proposed extensions (then I saw that you changed the label, and then I went and found your email). It's already more than 6. In the thread, there's also a proposal for BlockArgument that has yet to be added to the proposal. maybe you’ll agree that > if we want a predictable and reasonable frequent stream of language > editions, we have to avoid such delays when feasible. > I, for one, favour a regular cadence, too. On Mon, 6 Nov 2023 at 10:10, Joachim Breitner wrote: > Dear Committee, > > I’d like to get the committe involvement in GHC2024 started. The > current proposal is at > https://github.com/ghc-proposals/ghc-proposals/pull/613 > > https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst > > At the moment, six changes relative to CHC2021 are proposed by > committee and by community members. See the proposal for rationales. > > My goal is to have a decision in time for 9.10. I suggest we use > November to deliberate the proposals and maybe add more changes to the > list, and then vote in early December. We’ll put each change separately > on the ballot. > > > I know that there are ongoing discussions that could arguably affect > how we want the next GHC20xx to look like, in particular the just > opened #620, and I anticipate a desire to postpone GHC2024 until that > has been decided. But I recall that we postponed GHC2023 for (among > other reasons) for the same reason, and I wouldn’t be surprised that if > in a year we have yet another unresolved question that seems worth > waiting for. If this pattern reminds you of the GHC release process > before we introduced the regular cadence, then maybe you’ll agree that > if we want a predictable and reasonable frequent stream of language > editions, we have to avoid such delays when feasible. > > > So please let us know what you think of the proposed changes, what > other changes you want to see, or if you have qualms about the process. > > > 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 > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu Nov 9 14:16:44 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 9 Nov 2023 14:16:44 +0000 Subject: [ghc-steering-committee] GHC stability discussions In-Reply-To: References: Message-ID: One other interesting thread relating to GHC steering committee stability policy: #24154 . Simon On Sun, 5 Nov 2023 at 23:03, Simon Peyton Jones wrote: > Dear GHC Steering Committee > > We have several threads about GHC's stability in progress: > > - Proposal 601: GHC extension life cycle > . > This introduces the notion of a "Stable" and "Experimental" extension. It > was written by David C but has stalled now that he has stepped down as ED. > > - GHC Stability Goals > , > builds on #601 with general rules GR1-3. This is not a change to GHC > (hence not a GHC proposal) more a clarification about how the GHC Steering > Committee works. > > - Proposal 620: Extensions and warnings > . > This proposal keeps moving in the same direction, unifying warnings and > extensions. > > - Proposal 617: add -experimental flag > . This > builds on #601 by providing an enforcement mechanism. It is strongly > affected by #620. > > It would be good to get some of this decided. Too much is in the air at > the moment! Personally I think: > > - We can agree at least the Stable/Experimental part of #601 > - The Stability Goals seem fairly uncontroversial. Shall we just make > it part of the GHC Proposal process documentation > - #620 is new; your views would be welcome > - The approach to #617 may depend on the outcome of #620. > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Nov 21 17:18:38 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 21 Nov 2023 18:18:38 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: References: Message-ID: <1c1d06216a48bf7f2bac300925e67c24f376ea2e.camel@joachim-breitner.de> Hi, thanks for pushing more and well-justified proposals. Allow me to collect my thoughts on the individual additions proposed at https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst (generally, I’m guess I'm an inclusionist here) * DataKinds and TypeData Leaning towards yes for DataKinds, unsure for TypeData, and will bow in if this turns out to be contentious. It feels like a step in the right direction, but I am not a heavy user. * DerivingStrategies Being more explicit seems to be useful, e.g. with documentation, and it certainly doesn’t hurt. In favor. * DisambiguateRecordFields Small quality-of-life improvement, so sure, why not. In favor, unless I am missing something (peeks at Adam’s exam paper to copy the answer) * ExplicitNamespaces Again, being explicit is good, and it solves this oddity with language implications not being consistent with language editions (TypeOperators implies ExplicitNamespaces, but only the former is in gHC2021). In favor. * GADTs To me, they are just a normal part of what Haskell is these days. Let’s declare them so. * MonoLocalBinds Not an expert, but people say it’s simpler and needed to stay sane with GADTs. Yes, sometimes annoying (local parser helper etc.), but in those cases an explicit type signature is probably nice as well. Leaning towards yes. * ImpredicativeTypes Trusting Arnaud here, so sure. * LambdaCase In favor. I have seen code bases making good use of it, and it fits Haskell with it’s tendency to favor the point-free style. Happy to include (including the n-ary \cases variant). * RoleAnnotations Yes! It’s just something you need to build proper abstractions these days * TypeFamilies If we add GADTs (and MonoLocalBinds), I wouldn’t mind type families as well. I follow the argument that _if_ there is going to be a breaking change to their design in the future (evaluation order or something), it probably needs to be in a separate extension, given the amount of code out there already, and thus GHC2024 will continue to work. I hope. (It’s a bit optimistic for type-level stuff, which is not local to one module). Hmm, guess I ended up saying yes to all, but with varying levels of confidence. I trust the collective wisdom of the committee will find the right selection in the end. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From simon.peytonjones at gmail.com Tue Nov 21 21:06:46 2023 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 21 Nov 2023 21:06:46 +0000 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: <1c1d06216a48bf7f2bac300925e67c24f376ea2e.camel@joachim-breitner.de> References: <1c1d06216a48bf7f2bac300925e67c24f376ea2e.camel@joachim-breitner.de> Message-ID: > > * MonoLocalBinds > > Not an expert, but people say it’s simpler and needed to stay sane with > GADTs. Yes, sometimes annoying (local parser helper etc.), but in those > cases an explicit type signature is probably nice as well. Leaning > towards yes. > I agree. But I have been increasingly realising that really the extension should be called PolyLocalBinds, and MonoLocalBinds should be a synonym for NoPolyLocalBinds. Reason: extensions generally allow more programs, not fewer. PolyLocalBinds does that -- at the expense of less predictable type inference. To get predictable type inference with GADTs we switch PolyLocalBinds off. You may think this is just moving the deck chairs around, but I think this renaming is a more consistent story. Simon On Tue, 21 Nov 2023 at 17:18, Joachim Breitner wrote: > Hi, > > thanks for pushing more and well-justified proposals. > > Allow me to collect my thoughts on the individual additions proposed at > > https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst > (generally, I’m guess I'm an inclusionist here) > > * DataKinds and TypeData > > Leaning towards yes for DataKinds, unsure for TypeData, and will bow in > if this turns out to be contentious. It feels like a step in the right > direction, but I am not a heavy user. > > * DerivingStrategies > > Being more explicit seems to be useful, e.g. with documentation, and it > certainly doesn’t hurt. In favor. > > * DisambiguateRecordFields > > Small quality-of-life improvement, so sure, why not. In favor, unless I > am missing something (peeks at Adam’s exam paper to copy the answer) > > > * ExplicitNamespaces > > Again, being explicit is good, and it solves this oddity with language > implications not being consistent with language editions (TypeOperators > implies ExplicitNamespaces, but only the former is in gHC2021). In > favor. > > * GADTs > > To me, they are just a normal part of what Haskell is these days. Let’s > declare them so. > > * MonoLocalBinds > > Not an expert, but people say it’s simpler and needed to stay sane with > GADTs. Yes, sometimes annoying (local parser helper etc.), but in those > cases an explicit type signature is probably nice as well. Leaning > towards yes. > > * ImpredicativeTypes > > Trusting Arnaud here, so sure. > > * LambdaCase > > In favor. I have seen code bases making good use of it, and it fits > Haskell with it’s tendency to favor the point-free style. Happy to > include (including the n-ary \cases variant). > > * RoleAnnotations > > Yes! It’s just something you need to build proper abstractions these > days > > * TypeFamilies > > If we add GADTs (and MonoLocalBinds), I wouldn’t mind type families as > well. I follow the argument that _if_ there is going to be a breaking > change to their design in the future (evaluation order or something), > it probably needs to be in a separate extension, given the amount of > code out there already, and thus GHC2024 will continue to work. I hope. > (It’s a bit optimistic for type-level stuff, which is not local to one > module). > > > > Hmm, guess I ended up saying yes to all, but with varying levels of > confidence. I trust the collective wisdom of the committee will find > the right selection in the end. > > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue Nov 21 21:11:35 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 21 Nov 2023 22:11:35 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: References: <1c1d06216a48bf7f2bac300925e67c24f376ea2e.camel@joachim-breitner.de> Message-ID: <9afabc5a662a7584f27fc17e72c36906451f39fb.camel@joachim-breitner.de> Hi, Am Dienstag, dem 21.11.2023 um 21:06 +0000 schrieb Simon Peyton Jones: > > I agree.  But I have been increasingly realising that really the > extension should be called PolyLocalBinds, and MonoLocalBinds should > be a synonym for NoPolyLocalBinds. > > Reason: extensions generally allow more programs, not fewer.   > PolyLocalBinds does that -- at the expense of less predictable type > inference.  To get predictable type inference with GADTs we switch > PolyLocalBinds off. > > You may think this is just moving the deck chairs around, but I think > this renaming is a more consistent story. I am a big fan of nicely arranged seating on deck. So if we think it’s useful, I think we can add this to GHC2024 as NoPolyLocalBinds, retrofit PolyLocalBinds into the previous editions, and make the (No)MonoLocalBinds flags just aliases. I can add this as a rider to the GHC2024 vote. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Wed Nov 22 07:36:27 2023 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Wed, 22 Nov 2023 08:36:27 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: <9afabc5a662a7584f27fc17e72c36906451f39fb.camel@joachim-breitner.de> References: <1c1d06216a48bf7f2bac300925e67c24f376ea2e.camel@joachim-breitner.de> <9afabc5a662a7584f27fc17e72c36906451f39fb.camel@joachim-breitner.de> Message-ID: Joachim: you didn't opine on default type signatures. By the way, is it you kicking off the deliberation? On Tue, 21 Nov 2023 at 22:11, Joachim Breitner wrote: > Hi, > > Am Dienstag, dem 21.11.2023 um 21:06 +0000 schrieb Simon Peyton Jones: > > > > I agree. But I have been increasingly realising that really the > > extension should be called PolyLocalBinds, and MonoLocalBinds should > > be a synonym for NoPolyLocalBinds. > > > > Reason: extensions generally allow more programs, not fewer. > > PolyLocalBinds does that -- at the expense of less predictable type > > inference. To get predictable type inference with GADTs we switch > > PolyLocalBinds off. > > > > You may think this is just moving the deck chairs around, but I think > > this renaming is a more consistent story. > > > I am a big fan of nicely arranged seating on deck. So if we think it’s > useful, I think we can add this to GHC2024 as NoPolyLocalBinds, > retrofit PolyLocalBinds into the previous editions, and make the > (No)MonoLocalBinds flags just aliases. I can add this as a rider to the > GHC2024 vote. > > 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 > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Nov 22 09:41:10 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 22 Nov 2023 10:41:10 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: References: <1c1d06216a48bf7f2bac300925e67c24f376ea2e.camel@joachim-breitner.de> <9afabc5a662a7584f27fc17e72c36906451f39fb.camel@joachim-breitner.de> Message-ID: <240600b6abc6763b7bfc7373c1f3f4220c16113c.camel@joachim-breitner.de> Hi, Am Mittwoch, dem 22.11.2023 um 08:36 +0100 schrieb Arnaud Spiwack: > Joachim: you didn't opine on default type signatures. ups, scrolled past it. My gut feeling about that extension is that it feels relatively ad-hoc and specialized. Just look at the long list of “Detailed requirements for default type signatures” that go along with it! I’m hesitant to put into the curriculum of “contemporary Haskell”. We’ll see. > By the way, is it you kicking off the deliberation? I tried to kick it off already with the email from Nov 6, but yes, I am also writing my thoughts to stir more discussion. I hope we can start voting in two weeks. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From arnaud.spiwack at tweag.io Wed Nov 22 13:47:41 2023 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Wed, 22 Nov 2023 14:47:41 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: <240600b6abc6763b7bfc7373c1f3f4220c16113c.camel@joachim-breitner.de> References: <1c1d06216a48bf7f2bac300925e67c24f376ea2e.camel@joachim-breitner.de> <9afabc5a662a7584f27fc17e72c36906451f39fb.camel@joachim-breitner.de> <240600b6abc6763b7bfc7373c1f3f4220c16113c.camel@joachim-breitner.de> Message-ID: We're currently proposing the inclusion of 12 extensions. Someone also proposed BlockArguments in the thread, but it hasn't found a champion to add it to the proposal (I won't be this champion, I find myself quite unable to argue for or against it). This'd bring us to 59 of the ~130 extensions. Almost halfway there! (considering that some are deprecated or mere aliases, it's actually rather better than it looks). Maybe I should add QualifiedDo, too. I like QualifiedDo, and I don't envision any change to it. Any thoughts on this one? On Wed, 22 Nov 2023 at 10:41, Joachim Breitner wrote: > Hi, > > Am Mittwoch, dem 22.11.2023 um 08:36 +0100 schrieb Arnaud Spiwack: > > Joachim: you didn't opine on default type signatures. > > ups, scrolled past it. > > > My gut feeling about that extension is that it feels relatively ad-hoc > and specialized. Just look at the long list of “Detailed requirements > for default type signatures” that go along with it! I’m hesitant to put > into the curriculum of “contemporary Haskell”. We’ll see. > > > By the way, is it you kicking off the deliberation? > > I tried to kick it off already with the email from Nov 6, but yes, I am > also writing my thoughts to stir more discussion. I hope we can start > voting in two weeks. > > > 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 > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Wed Nov 22 14:42:50 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 22 Nov 2023 15:42:50 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: References: <1c1d06216a48bf7f2bac300925e67c24f376ea2e.camel@joachim-breitner.de> <9afabc5a662a7584f27fc17e72c36906451f39fb.camel@joachim-breitner.de> <240600b6abc6763b7bfc7373c1f3f4220c16113c.camel@joachim-breitner.de> Message-ID: <4cc98dd557556f21a89c0c755da3901dff5e1092.camel@joachim-breitner.de> Hi, Am Mittwoch, dem 22.11.2023 um 14:47 +0100 schrieb Arnaud Spiwack: > Someone also proposed BlockArguments in the thread, but it hasn't > found a champion to add it to the proposal (I won't be this champion, > I find myself quite unable to argue for or against it). actually, I like that one, and just put it on the tally. Having worked with languages that already have it (lean) I appreciate its de-noising effect on syntax. > This'd bring us to 59 of the ~130 extensions. Almost halfway there! > (considering that some are deprecated or mere aliases, it's actually > rather better than it looks). Now is there a way to `git rebase -i` our collective minds so that instead of 59 extensions, we have 4 language editions? :) > Maybe I should add QualifiedDo, too. I like QualifiedDo, and I don't > envision any change to it. Any thoughts on this one? Feels a bit too new to me, I haven’t seen it in action enough (but I also haven’t been looking). Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Wed Nov 22 20:25:46 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 22 Nov 2023 21:25:46 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: References: Message-ID: Hi, it was brought to my attention that the proposal that introduced GHC20xx actually laid out a specific process to decide about the next GHC20xx: https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst#process This includes “secretary tallies usage on Hackage” and “secretary runs a public poll”, and also wants to do all these things on _all_ extensions, instead on focusing on those that least someone nominates, and requires every committee member to independently propose a set of extensions. I’m not sure to what extend we should tie ourselves to a process we imagined three years ago. But if anyone things we should do one of these things, we can. I guess I could at least do a simple poll on discourse with the currently proposed extensions. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From mail at joachim-breitner.de Wed Nov 22 21:11:57 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Wed, 22 Nov 2023 22:11:57 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: References: Message-ID: <7902ee9068fdce04a3f872c908f69d9bb9375cc0.camel@joachim-breitner.de> Am Mittwoch, dem 22.11.2023 um 21:25 +0100 schrieb Joachim Breitner: > I guess I could at least do a simple poll on discourse with the > currently proposed extensions. Now at https://discourse.haskell.org/t/ghc2024-community-input/8168. Not perfect (e.g. number of options on Discourse are limited), but it’s something. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From chris at chrisdornan.com Thu Nov 23 04:33:42 2023 From: chris at chrisdornan.com (Chris Dornan) Date: Thu, 23 Nov 2023 04:33:42 +0000 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: References: Message-ID: Joachim, Gathering some data might be a good idea, provided the secretary is banned from doing this! (I mean it is really, really bad idea to load up the secretary with these kinds of activities.) I am not in favour of polling. We collect that kind of data in the survey -- can we not use that? Advertising the ghc-proposal issue in the usual places should be sufficient. Otherwise I fear we would be inviting problems and poor decisions. Chris > On 22 Nov 2023, at 20:25, Joachim Breitner wrote: > > Hi, > > it was brought to my attention that the proposal that introduced > GHC20xx actually laid out a specific process to decide about the next > GHC20xx: > https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst#process > > This includes “secretary tallies usage on Hackage” and “secretary runs > a public poll”, and also wants to do all these things on _all_ > extensions, instead on focusing on those that least someone nominates, > and requires every committee member to independently propose a set of > extensions. > > I’m not sure to what extend we should tie ourselves to a process we > imagined three years ago. But if anyone things we should do one of > these things, we can. > > I guess I could at least do a simple poll on discourse with the > currently proposed extensions. > > 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 From mail at joachim-breitner.de Thu Nov 23 07:54:57 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 23 Nov 2023 08:54:57 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: References: Message-ID: Hi, Am Donnerstag, dem 23.11.2023 um 04:33 +0000 schrieb Chris Dornan: > I am not in favour of polling. We collect that kind of data in the survey -- can we not use that? unfortunately it seems the survey hasn’t happened for a while. Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From adam at well-typed.com Wed Nov 29 08:24:54 2023 From: adam at well-typed.com (Adam Gundry) Date: Wed, 29 Nov 2023 08:24:54 +0000 Subject: [ghc-steering-committee] #493: SPECIALISE with expressions, rec: accept Message-ID: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com> Dear all, Richard and Simon propose to generalise SPECIALISE pragmas to allow expressions, not just type signatures: https://github.com/ghc-proposals/ghc-proposals/pull/493 https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst This does not add anything fundamentally new, because such SPECIALISE pragmas can be translated using the existing RULES machinery, but it does make several idioms substantially more convenient: * Using type applications in a SPECIALISE pragma to avoid repetition * Manual call-pattern specialisation * Loop unrolling Thus I propose we accept this proposal. Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England From arnaud.spiwack at tweag.io Wed Nov 29 09:24:54 2023 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Wed, 29 Nov 2023 10:24:54 +0100 Subject: [ghc-steering-committee] #493: SPECIALISE with expressions, rec: accept In-Reply-To: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com> References: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com> Message-ID: This does look quite reasonable. And, off the top of my head, rather natural to implement. I vote accept. On Wed, 29 Nov 2023 at 09:25, Adam Gundry wrote: > Dear all, > > Richard and Simon propose to generalise SPECIALISE pragmas to allow > expressions, not just type signatures: > > https://github.com/ghc-proposals/ghc-proposals/pull/493 > > https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst > > This does not add anything fundamentally new, because such SPECIALISE > pragmas can be translated using the existing RULES machinery, but it > does make several idioms substantially more convenient: > > * Using type applications in a SPECIALISE pragma to avoid repetition > > * Manual call-pattern specialisation > > * Loop unrolling > > Thus I propose we accept this proposal. > > Cheers, > > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee at haskell.org > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu Nov 30 07:55:07 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 30 Nov 2023 08:55:07 +0100 Subject: [ghc-steering-committee] Please review #606: 281 to use atype instead of ktype, Shepherd: Richard Message-ID: <29326345282a6b27fe88846e3eef6613f0a90c8a.camel@joachim-breitner.de> Dear Committee, Vladislav Zavialov proposes a grammar amendment to types in terms: https://github.com/ghc-proposals/ghc-proposals/pull/606 https://github.com/ghc-proposals/ghc-proposals/pull/606/files I’d like to nominate Richard as the shepherd. Please guide us to a conclusion as outlined in https://github.com/ghc-proposals/ghc-proposals#committee-process Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/ From marlowsd at gmail.com Thu Nov 30 08:02:26 2023 From: marlowsd at gmail.com (Simon Marlow) Date: Thu, 30 Nov 2023 08:02:26 +0000 Subject: [ghc-steering-committee] #493: SPECIALISE with expressions, rec: accept In-Reply-To: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com> References: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com> Message-ID: Sounds like a great idea. Simon On Wed, 29 Nov 2023 at 08:25, Adam Gundry wrote: > Dear all, > > Richard and Simon propose to generalise SPECIALISE pragmas to allow > expressions, not just type signatures: > > https://github.com/ghc-proposals/ghc-proposals/pull/493 > > https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst > > This does not add anything fundamentally new, because such SPECIALISE > pragmas can be translated using the existing RULES machinery, but it > does make several idioms substantially more convenient: > > * Using type applications in a SPECIALISE pragma to avoid repetition > > * Manual call-pattern specialisation > > * Loop unrolling > > Thus I propose we accept this proposal. > > Cheers, > > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > _______________________________________________ > 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: From vlad.z.4096 at gmail.com Thu Nov 30 12:14:40 2023 From: vlad.z.4096 at gmail.com (Vladislav Zavialov) Date: Thu, 30 Nov 2023 13:14:40 +0100 Subject: [ghc-steering-committee] #493: SPECIALISE with expressions, rec: accept In-Reply-To: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com> References: <834995b6-5097-46b5-933b-7cbeacb48234@well-typed.com> Message-ID: Great idea. I've worked on some code that uses SPECIALIZE pragmas with large type signatures, and it would become considerably more elegant if it could use type applications instead. Vlad On Wed, Nov 29, 2023 at 9:25 AM Adam Gundry wrote: > Dear all, > > Richard and Simon propose to generalise SPECIALISE pragmas to allow > expressions, not just type signatures: > > https://github.com/ghc-proposals/ghc-proposals/pull/493 > > https://github.com/goldfirere/ghc-proposals/blob/specialise/proposals/0000-specialise-expressions.rst > > This does not add anything fundamentally new, because such SPECIALISE > pragmas can be translated using the existing RULES machinery, but it > does make several idioms substantially more convenient: > > * Using type applications in a SPECIALISE pragma to avoid repetition > > * Manual call-pattern specialisation > > * Loop unrolling > > Thus I propose we accept this proposal. > > Cheers, > > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > _______________________________________________ > 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: From mail at joachim-breitner.de Thu Nov 30 18:30:34 2023 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 30 Nov 2023 19:30:34 +0100 Subject: [ghc-steering-committee] GHC2024 committee deliberation In-Reply-To: <7902ee9068fdce04a3f872c908f69d9bb9375cc0.camel@joachim-breitner.de> References: <7902ee9068fdce04a3f872c908f69d9bb9375cc0.camel@joachim-breitner.de> Message-ID: <76dc28bb599e5c137b52b1994abcac49370849bd.camel@joachim-breitner.de> Hi all, Am Mittwoch, dem 22.11.2023 um 22:11 +0100 schrieb Joachim Breitner: > Am Mittwoch, dem 22.11.2023 um 21:25 +0100 schrieb Joachim Breitner: > > I guess I could at least do a simple poll on discourse with the > > currently proposed extensions. > > Now at https://discourse.haskell.org/t/ghc2024-community-input/8168. > Not perfect (e.g. number of options on Discourse are limited), but it’s > something. after a week, we got 137 people to vote. This is of course not representative of our full target audience, but still useful input. For example, I didn’t expect LambdaCase to be that popular (84%). Other interesting bits: * DerivingVia is the most popular extension that we do _not_ have on the ballot for 2024, with 62%. I think it's reasonable, I woudn’t mind maturing it a for another edition cycle or so; there was talk about improving error messages. * Lots of discussion about BlockArguments, but mostly along the lines of “I use it (in Haskell or other languages), it’s great” vs. “It don’t use it, it looks weird to me.”. My hypothesis is that it is no harder to get used to than application-by-juxtaposition or $ or other keywords, so I’m still in favor. Anyways, have a look if you are curious, and take it into account in your voting if I want. So where do we stand? Does everyone in the committee have the information they need to cast a vote? Should we just go ahead with voting, or would some committee members maybe share an assessment of the currently proposed extensions at https://github.com/ghc-proposals/ghc-proposals/blob/joachim/ghc2024/proposals/0000-ghc2024.rst to help people decide? Cheers, Joachim -- Joachim Breitner mail at joachim-breitner.de http://www.joachim-breitner.de/