From adam at well-typed.com Tue May 6 12:38:17 2025 From: adam at well-typed.com (Adam Gundry) Date: Tue, 6 May 2025 13:38:17 +0100 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: <9c24cac5-4dc8-4886-a589-750e10045a04@well-typed.com> References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com> <20241102172853.d250122548113c86708fb24a@mega-nerd.com> <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> <9c24cac5-4dc8-4886-a589-750e10045a04@well-typed.com> Message-ID: Hi everyone, After a few rounds of editing to improve the spec, Simon has declared himself satisfied with #668. It now generalises OverloadedRecordDot and OverloadedRecordUpdate to support arbitrary field labels (consistent with OverloadedLabels) and does some general tidying up of the spec: https://github.com/ghc-proposals/ghc-proposals/pull/668 https://github.com/parsonsmatt/ghc-proposals/blob/patch-1/proposals/0282-record-dot-syntax.rst I believe there were no other concerns, so unless anyone objects I plan to declare this accepted in a week or so. Cheers, Adam On 08/04/2025 10:00, Adam Gundry via ghc-steering-committee wrote: > I have now updated this proposal on the basis of the vote: > > https://github.com/ghc-proposals/ghc-proposals/pull/668 > > Please take a look and let me know if you are happy with the current > state of the PR, or have any remaining concerns. > > Thanks, > > Adam > > P.S. I will be away on holiday over the next couple of weeks, so > apologies in advance for any delays in response. > > > On 07/04/2025 16:21, Adam Gundry via ghc-steering-committee wrote: >> Thanks everyone for your responses to this. There seems to be a fairly >> clear consensus that the preferred option is B. (5 votes have B in >> first place, then 3 others either rate A and B equally or weakly >> prefer A to B.) Thus I plan to revise the proposal accordingly. >> >> Adam >> >> >> >> On 02/04/2025 10:26, Matthías Páll Gissurarson via >> ghc-steering-committee wrote: >>> I have a slight preference for B over A. The point that [2] brings up >>> is a good one, it seems better to allow row.“foo bar”, especially >>> when reading CSV or JSON as they mention. >>> >>> So my preference is B>A>C>D >>> >>> /Matti Palli >>> >>> >>> On Wed, Apr 2, 2025 at 07:56 Arnaud Spiwack via >>> ghc-steering-committee >> > wrote: >>> >>>     My preference is >>>     A>B>C>D >>> >>>     Though my preference between A and B is weak. Whatever's easier >>> really. >>> >>>     On Thu, 20 Mar 2025 at 19:04, Simon Marlow via >>>     ghc-steering-committee >>     > wrote: >>> >>>         I don't feel all that strongly except that C seems like a bad >>>         idea. A = B > D > C >>> >>>         Cheers >>>         Simon >>> >>>         On Wed, 19 Mar 2025 at 21:49, Adam Gundry via >>>         ghc-steering-committee >>         > wrote: >>> >>>             Hi everyone, >>> >>>             This proposal [0] has been lingering for quite some time, >>>             unfortunately. >>>             So we can make progress, I've tried to summarise our options >>>             below; >>>             please vote for your preferred option in the next week or >>>             two.  Once we >>>             have decided on our preferred course of action, I'll make >>>             any necessary >>>             editorial changes to the proposal. >>> >>>             To recap, the idea is to extend OverloadedRecordDot such >>>             that it permits >>>             record selection expressions such as >>> >>>                  foo.type   ->   getField @"type" foo >>> >>>             even though `type` is a keyword and hence not a valid record >>>             field in a >>>             traditional datatype declarations. This is primarily >>>             motivated by the >>>             use of OverloadedRecordDot in libraries such as `persistent` >>>             (see [1]), >>>             which will generate instances like this: >>> >>>                  instance HasField "type" SomeRecord SomeField1 where >>>                    getField = ... >>> >>>                  instance HasField "bar" SomeRecord SomeField2 where >>>                    getField = ... >>> >>>             Both these instances are accepted, so it is quite surprising >>>             and >>>             annoying that `foo.type` is a syntax error, even though >>>             `foo.bar` will >>>             be accepted (and turn into a call to `getField @"bar"`). >>> >>>             As a small syntactic change, the proposal has lead to quite >>>             some >>>             discussion and a few plausible alternatives: >>> >>>                A. Accept the proposal as it stands, since it is the >>>             smallest change >>>             that resolves the issue. >>> >>>                B. Extend the proposal to permit still wider syntax, e.g. >>>             `foo.Uppercase` or `foo."quoted string"`, motivated by >>>             consistency with >>>             OverloadedLabels and use cases such as [2]. This seems >>>             reasonable to me. >>> >>>                C. Extend the proposal to permit keywords such as `type` >>>             to be used as >>>             field names in traditional record syntax, e.g. `data Foo = >>>             Foo { type :: >>>             Int }`. In my view this is unnecessary complexity that >>>             mistakenly >>>             conflates OverloadedRecordDot with traditional record >>>             syntax; the >>>             motivation for keywords as selector names comes from uses of >>>             OverloadedRecordDot that do not involve traditional record >>>             syntax. >>> >>>                D. Reject the proposal entirely, e.g. due to worries >>>             about syntax >>>             highlighting. >>> >>>             Please reply with your preference order amongst these >>>             options. My vote >>>             is B > A > C > D. >>> >>>             Thanks, >>> >>>             Adam >>> >>> >>>             [0] https://github.com/ghc-proposals/ghc-proposals/pull/668 >>>             >>> >>>             [1] >>> https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397 >>> >>>             [2] >>> https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901 >>> >>> >>> >>>             On 05/11/2024 13:58, Arnaud Spiwack wrote: >>>              > I have no opinion on this. But I've seen two points in >>>             the thread which >>>              > make sense: Vlad, our guardian of the parser, says that >>>             it's a good >>>              > idea, and the comparison with OverloadedLabel (made by >>>             Vlad and others) >>>              > is apt, and the symmetry is desirable. Ideally the >>>             comparison with >>>              > OverloadedLabel should be made in the Alternatives >>>             section, but I don't >>>              > feel like insisting about it :) . >>>              > >>>              > On Sat, 2 Nov 2024 at 21:21, Simon Peyton Jones >>>              > >>             >>>             >>             >> wrote: >>>              > >>>              >     I'm in support too, but I have made some substantive >>>             suggestions on >>>              >     the GitHub ticket that I'd like to see addressed >>>             before we tie a bow >>>              >     on this. >>>              > >>>              >     Simon >>>              > >>>              >     On Sat, 2 Nov 2024 at 09:25, Sebastian Graf >>>             >>>              >     >>             >> wrote: >>>              > >>>              >         I'm in support as well, but would like to see a >>>             single >>>              >         clarifying sentence added to the proposal. >>>              > >>> https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > >>>              > >>>              >         Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de >>>             Castro Lopo >>>              >          >>>             >>: >>>              > >>>              > >>>              > >>>              >             I am in support. >>>              > >>>              >             Erik >>>              > >>>              >             Matthías Páll Gissurarson wrote: >>>              > >>>              >              > I’m in support. No need to keep >>>             reservations longer than >>>              >             necessary. >>>              >              > >>>              >              > /Matti Palli >>>              >              > >>>              >              > >>>              >              > On Fri, Nov 1, 2024 at 23:22 Malte Ott >>>              >             >>             >>             >> wrote: >>>              >              > >>>              >              > > >>>              >              > > On 2024-10-29 20:12, Adam Gundry wrote: >>>              >              > > > >>>              > https://github.com/ghc-proposals/ghc-proposals/pull/668 >>>             >>>              >  >>             > >>>              >              > > >>>              >              > > I’m in support. >>>              >              > > >>>              >              > > Best >>>              >              > > Malte >>>              >              > > >>>             _______________________________________________ >>>              >              > > ghc-steering-committee mailing list >>>              >              > > ghc-steering-committee at haskell.org >>>             >>>              >             >>             > >>>              >              > > >>>              > >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > >>>              >              > > >>>              > >>>              > >>>              >             -- >>>              > >>>  ---------------------------------------------------------------------- >>>              >             Erik de Castro Lopo >>>              > http://www.mega-nerd.com/ >>>             > >>>              >  _______________________________________________ >>>              >             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 > >>>              > >>>              > >>>              > >>>              > -- >>>              > Arnaud Spiwack >>>              > Director, Research at https://moduscreate.com >>>             >>             > >>>              > and https://tweag.io >>             >. >>>              > >>>              > _______________________________________________ >>>              > ghc-steering-committee mailing list >>>              > ghc-steering-committee at haskell.org >>>             >>>              > >>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee >>> >>>             --             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 >>> >>>         _______________________________________________ >>>         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 . >>>     _______________________________________________ >>>     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 -- 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 adam at well-typed.com Tue May 6 12:40:07 2025 From: adam at well-typed.com (Adam Gundry) Date: Tue, 6 May 2025 13:40:07 +0100 Subject: [ghc-steering-committee] Please review #632: introduction of new language editions (inc. GHC2024) In-Reply-To: References: <6c43809d-cbd0-4cd0-93fd-13b0523077b0@well-typed.com> Message-ID: <9b072e70-8872-496e-8101-7a4419be908b@well-typed.com> Hi Simon, It looks like we're probably in a position to declare this proposal accepted? Thanks, Adam On 09/04/2025 10:34, Simon Marlow wrote: > Committee: I'm proposing we accept #632, which will change the policy > for new language editions such that new GHC versions will use the latest > language edition by default if one is not specified. GHC 9.10 didn't do > this, but we'll aim to do it in the future. > > Not specifying an explicit language edition is a relatively rare > situation - in particular Cabal always sets the language edition. The > notable cases where the default language edition will be used is when > invoking "ghc" or "ghci" directly from the shell; see the proposal for > more details. > >  If you have comments on the proposal, please discuss on github: > https://github.com/ghc-proposals/ghc-proposals/pull/632 > > > I think we should be able to reach consensus pretty quickly on this one, > shall we say 2 weeks for comments? > > Cheers > Simon > > On Tue, 8 Apr 2025 at 09:17, Adam Gundry > wrote: > > Dear Committee, > > I propose to amend the process for introducing new language editions, > such that GHC always uses the latest language edition by default. In > particular this would change the default language edition to GHC2024 > (it > currently remains GHC2021): > > https://github.com/ghc-proposals/ghc-proposals/pull/632 > > https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0372-ghc-extensions.rst#breaking-changes > https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#implementation-plan > > I'd like to invite Simon Marlow to be the shepherd. (Originally I was > shepherding this amendment myself, in the hope that it would be a quick > amendment in time for GHC 9.10, but that was clearly a forlorn hope!) > > Please guide us to a conclusion as outlined in > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > 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 marlowsd at gmail.com Tue May 6 12:58:41 2025 From: marlowsd at gmail.com (Simon Marlow) Date: Tue, 6 May 2025 13:58:41 +0100 Subject: [ghc-steering-committee] Please review #632: introduction of new language editions (inc. GHC2024) In-Reply-To: <9b072e70-8872-496e-8101-7a4419be908b@well-typed.com> References: <6c43809d-cbd0-4cd0-93fd-13b0523077b0@well-typed.com> <9b072e70-8872-496e-8101-7a4419be908b@well-typed.com> Message-ID: Yes, thanks for the reminder Adam. Ship it. On Tue, 6 May 2025 at 13:40, Adam Gundry wrote: > Hi Simon, > > It looks like we're probably in a position to declare this proposal > accepted? > > Thanks, > > Adam > > > On 09/04/2025 10:34, Simon Marlow wrote: > > Committee: I'm proposing we accept #632, which will change the policy > > for new language editions such that new GHC versions will use the latest > > language edition by default if one is not specified. GHC 9.10 didn't do > > this, but we'll aim to do it in the future. > > > > Not specifying an explicit language edition is a relatively rare > > situation - in particular Cabal always sets the language edition. The > > notable cases where the default language edition will be used is when > > invoking "ghc" or "ghci" directly from the shell; see the proposal for > > more details. > > > > If you have comments on the proposal, please discuss on github: > > https://github.com/ghc-proposals/ghc-proposals/pull/632 > > > > > > I think we should be able to reach consensus pretty quickly on this one, > > shall we say 2 weeks for comments? > > > > Cheers > > Simon > > > > On Tue, 8 Apr 2025 at 09:17, Adam Gundry > > wrote: > > > > Dear Committee, > > > > I propose to amend the process for introducing new language editions, > > such that GHC always uses the latest language edition by default. In > > particular this would change the default language edition to GHC2024 > > (it > > currently remains GHC2021): > > > > https://github.com/ghc-proposals/ghc-proposals/pull/632 > > > > > https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0372-ghc-extensions.rst#breaking-changes > < > https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0372-ghc-extensions.rst#breaking-changes > > > > > https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#implementation-plan > < > https://github.com/adamgundry/ghc-proposals/blob/ghc2024-amendment/proposals/0613-ghc2024.rst#implementation-plan > > > > > > I'd like to invite Simon Marlow to be the shepherd. (Originally I was > > shepherding this amendment myself, in the hope that it would be a > quick > > amendment in time for GHC 9.10, but that was clearly a forlorn hope!) > > > > Please guide us to a conclusion as outlined in > > https://github.com/ghc-proposals/ghc-proposals#committee-process > > > > > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eric at seidel.io Sun May 18 15:38:08 2025 From: eric at seidel.io (Eric Seidel) Date: Sun, 18 May 2025 10:38:08 -0500 Subject: [ghc-steering-committee] Stepping down from the Steering Committee Message-ID: Hi folks, I have not had time to participate in Committee activities for a few months now. And upon reflection, I don't think that will change in the near future. So I think it's time for me to step down from the Committee and make room for someone else with more capacity to devote to improving Haskell. It makes me sad because I still care deeply about Haskell and its community. But I think it's the right decision for me and for the community. Thank you all, it's been an honor to serve. Eric From adam at well-typed.com Mon May 19 06:55:27 2025 From: adam at well-typed.com (Adam Gundry) Date: Mon, 19 May 2025 07:55:27 +0100 Subject: [ghc-steering-committee] Stepping down from the Steering Committee In-Reply-To: References: Message-ID: Hi Eric, Thank you for your service on the Steering Committee over many years, and for all your contributions to GHC and the Haskell community. We are very grateful for all your efforts, and wish you all the best for the future. Of course, to the extent that time permits, your input on proposals is still warmly welcome. Best wishes, Adam On 18/05/2025 16:38, Eric Seidel via ghc-steering-committee wrote: > Hi folks, > > I have not had time to participate in Committee activities for a few months now. And upon reflection, I don't think that will change in the near future. > > So I think it's time for me to step down from the Committee and make room for someone else with more capacity to devote to improving Haskell. > > It makes me sad because I still care deeply about Haskell and its community. But I think it's the right decision for me and for the community. > > Thank you all, it's been an honor to serve. > Eric -- 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 simon.peytonjones at gmail.com Mon May 19 09:15:55 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 19 May 2025 10:15:55 +0100 Subject: [ghc-steering-committee] Stepping down from the Steering Committee In-Reply-To: References: Message-ID: Eric Thank you so much -- you have contributed a lot. Simon On Sun, 18 May 2025 at 16:41, Eric Seidel via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > Hi folks, > > I have not had time to participate in Committee activities for a few > months now. And upon reflection, I don't think that will change in the near > future. > > So I think it's time for me to step down from the Committee and make room > for someone else with more capacity to devote to improving Haskell. > > It makes me sad because I still care deeply about Haskell and its > community. But I think it's the right decision for me and for the community. > > Thank you all, it's been an honor to serve. > Eric > _______________________________________________ > 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: