From arnaud.spiwack at tweag.io Wed Apr 2 05:56:04 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Wed, 2 Apr 2025 14:56:04 +0900 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com> <20241102172853.d250122548113c86708fb24a@mega-nerd.com> <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> Message-ID: 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 < ghc-steering-committee at haskell.org> 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 < > ghc-steering-committee at haskell.org> 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 >> < >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpg at mpg.is Wed Apr 2 09:26:03 2025 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Wed, 2 Apr 2025 11:26:03 +0200 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com> <20241102172853.d250122548113c86708fb24a@mega-nerd.com> <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> Message-ID: 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 < ghc-steering-committee at haskell.org> 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 < > ghc-steering-committee at haskell.org> 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 < >> ghc-steering-committee at haskell.org> 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 >>> < >>> 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 >>> < >>> 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 >>> < >>> 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 >>> < >>> 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 >>> < >>> 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Mon Apr 7 15:21:10 2025 From: adam at well-typed.com (Adam Gundry) Date: Mon, 7 Apr 2025 16:21:10 +0100 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com> <20241102172853.d250122548113c86708fb24a@mega-nerd.com> <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> Message-ID: 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 Apr 8 07:39:36 2025 From: adam at well-typed.com (Adam Gundry) Date: Tue, 8 Apr 2025 08:39:36 +0100 Subject: [ghc-steering-committee] Please review #687: Monad of No Return Message-ID: <2dfa46f5-22e5-41df-9a57-472b634af233@well-typed.com> Dear Committee, Benjamin proposes to revive and move forward the Monad of No Return proposal: https://github.com/ghc-proposals/ghc-proposals/pull/687 https://github.com/L0neGamer/ghc-proposals/blob/amending-mrp/proposals/0000-amending-mrp.rst I'd like to nominate Matthías as the shepherd. 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 adam at well-typed.com Tue Apr 8 08:17:32 2025 From: adam at well-typed.com (Adam Gundry) Date: Tue, 8 Apr 2025 09:17:32 +0100 Subject: [ghc-steering-committee] Please review #632: introduction of new language editions (inc. GHC2024) Message-ID: <6c43809d-cbd0-4cd0-93fd-13b0523077b0@well-typed.com> 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 adam at well-typed.com Tue Apr 8 09:00:01 2025 From: adam at well-typed.com (Adam Gundry) Date: Tue, 8 Apr 2025 10:00:01 +0100 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: References: <414a9ae5-6602-4cc7-9c04-97fd79c90681@well-typed.com> <20241102172853.d250122548113c86708fb24a@mega-nerd.com> <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> Message-ID: <9c24cac5-4dc8-4886-a589-750e10045a04@well-typed.com> 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 jakob.bruenker at gmail.com Wed Apr 9 02:30:45 2025 From: jakob.bruenker at gmail.com (=?UTF-8?Q?Jakob_Br=C3=BCnker?=) Date: Wed, 9 Apr 2025 04:30:45 +0200 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, The updated proposal looks good to me! Jakob On Tue, Apr 8, 2025 at 11:00 AM Adam Gundry via ghc-steering-committee < ghc-steering-committee at haskell.org> 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 > < > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397 > > > >> > >> [2] > >> > >> > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901 > < > 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 > < > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003> > < > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > < > 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 > >> > >> malte.ott at maralorn.de > >> >> 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 < > 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 < > 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 < > 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 < > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> > >> > >> > > >> > > >> > > >> > -- > >> > Arnaud Spiwack > >> > Director, Research at https://moduscreate.com > >> >> > > >> > and https://tweag.io < > 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 < > 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 > >> > >> < > https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g > > > >> > >> _______________________________________________ > >> ghc-steering-committee mailing list > >> ghc-steering-committee at haskell.org > >> > >> > >> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < > 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 < > 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 < > 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 > > _______________________________________________ > 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 simon.peytonjones at gmail.com Wed Apr 9 09:02:17 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 9 Apr 2025 10:02:17 +0100 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: 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: I'm thumbs up -- but I have added a post with a list of suggested presentational cleanups. (Adam if you are worn out I suppose I could execute on them myself. I don't want to keep erecting new obstacles.) Simon On Wed, 9 Apr 2025 at 03:31, Jakob Brünker via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > Hi, > > The updated proposal looks good to me! > > Jakob > > On Tue, Apr 8, 2025 at 11:00 AM Adam Gundry via ghc-steering-committee < > ghc-steering-committee at haskell.org> 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 >> < >> https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397 >> > >> >> >> >> [2] >> >> >> >> >> https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901 >> < >> 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 >> < >> https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003> >> < >> https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 >> < >> 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 >> >> > > erikd at mega-nerd.com> >> >> > >>>: >> >> > >> >> > >> >> > >> >> > 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 >> >> > > >> > malte.ott at maralorn.de >> >> >> 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 < >> 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 >> >> >> >> < >> https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g >> > >> >> >> >> _______________________________________________ >> >> 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 >> >> _______________________________________________ >> 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: From marlowsd at gmail.com Wed Apr 9 09:34:15 2025 From: marlowsd at gmail.com (Simon Marlow) Date: Wed, 9 Apr 2025 10:34:15 +0100 Subject: [ghc-steering-committee] Please review #632: introduction of new language editions (inc. GHC2024) In-Reply-To: <6c43809d-cbd0-4cd0-93fd-13b0523077b0@well-typed.com> References: <6c43809d-cbd0-4cd0-93fd-13b0523077b0@well-typed.com> Message-ID: 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Wed Apr 9 11:18:59 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 9 Apr 2025 12:18:59 +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: I'm in support. I have added a suggested edit. On Wed, 9 Apr 2025 at 10:34, Simon Marlow via ghc-steering-committee < ghc-steering-committee at haskell.org> 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 >> > _______________________________________________ > 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 malte.ott at maralorn.de Wed Apr 9 15:22:47 2025 From: malte.ott at maralorn.de (Malte Ott) Date: Wed, 09 Apr 2025 17:22:47 +0200 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: I like this very much. In favor! On 9 April 2025 13:18:59 CEST, Simon Peyton Jones via ghc-steering-committee wrote: >I'm in support. I have added a suggested edit. > >On Wed, 9 Apr 2025 at 10:34, Simon Marlow via ghc-steering-committee < >ghc-steering-committee at haskell.org> 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 >>> >> _______________________________________________ >> 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 malte.ott at maralorn.de Wed Apr 9 22:13:23 2025 From: malte.ott at maralorn.de (Malte Ott) Date: Thu, 10 Apr 2025 00:13:23 +0200 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: References: <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> <9c24cac5-4dc8-4886-a589-750e10045a04@well-typed.com> Message-ID: I like this a lot. In favor! On 2025-04-09 10:02, Simon Peyton Jones via ghc-steering-committee wrote: > I'm thumbs up -- but I have added a post with a list of suggested > presentational cleanups. > > (Adam if you are worn out I suppose I could execute on them myself. I > don't want to keep erecting new obstacles.) > > Simon > > On Wed, 9 Apr 2025 at 03:31, Jakob Brünker via ghc-steering-committee > <[1]ghc-steering-committee at haskell.org> wrote: > > Hi, > > The updated proposal looks good to me! > > Jakob > > On Tue, Apr 8, 2025 at 11:00 AM Adam Gundry via ghc-steering-committee > <[2]ghc-steering-committee at haskell.org> wrote: > > I have now updated this proposal on the basis of the vote: > > [3]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 > >> <[4]ghc-steering-committee at haskell.org > >> > 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 <[6]ghc-steering-committee at haskell.org > >> > 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 > <[8]ghc-steering-committee at haskell.org > >> > 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] > [10]https://github.com/ghc-proposals/ghc-proposals/pull/668 > >> > <[11]https://github.com/ghc-proposals/ghc-proposals/pull/668> > >> > >> [1] > >> > >> > [12]https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecom > ment-2561282397 > <[13]https://github.com/ghc-proposals/ghc-proposals/pull/668#issueco > mment-2561282397> > >> > >> [2] > >> > >> > [14]https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecom > ment-2564274901 > <[15]https://github.com/ghc-proposals/ghc-proposals/pull/668#issueco > mment-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 > >> > <[16]simon.peytonjones at gmail.com > >> > >> >> >> 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 > >> <[20]sgraf1337 at gmail.com > > >> > >> >> wrote: > >> > > >> > I'm in support as well, but would like to > see a > >> single > >> > clarifying sentence added to the proposal. > >> > > >> > >> > [24]https://github.com/ghc-proposals/ghc-proposals/pull/668#discussi > on_r1826533003 > <[25]https://github.com/ghc-proposals/ghc-proposals/pull/668#discuss > ion_r1826533003> > <[26]https://github.com/ghc-proposals/ghc-proposals/pull/668#discuss > ion_r1826533003 > <[27]https://github.com/ghc-proposals/ghc-proposals/pull/668#discuss > ion_r1826533003>> > >> > > >> > Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb > Erik de > >> Castro Lopo > >> > <[28]erikd at mega-nerd.com > > >> >>: > >> > > >> > > >> > > >> > 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 > >> > <[32]malte.ott at maralorn.de > >> > >> >> wrote: > >> > > > >> > > > > >> > > > On 2024-10-29 20:12, Adam Gundry > wrote: > >> > > > > > >> > > [36]https://github.com/ghc-proposals/ghc-proposals/pull/668 > >> > <[37]https://github.com/ghc-proposals/ghc-proposals/pull/668> > >> > > >> <[38]https://github.com/ghc-proposals/ghc-proposals/pull/668 > >> > <[39]https://github.com/ghc-proposals/ghc-proposals/pull/668>> > >> > > > > >> > > > I’m in support. > >> > > > > >> > > > Best > >> > > > Malte > >> > > > > >> _______________________________________________ > >> > > > ghc-steering-committee mailing > list > >> > > > > [40]ghc-steering-committee at haskell.org > >> > >> > > >> > > >> > > > > >> > > >> > >> > [44]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > <[45]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee> > <[46]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee > <[47]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee>> > >> > > > > >> > > >> > > >> > -- > >> > > >> > -------------------------------------------------------------------- > -- > >> > Erik de Castro Lopo > >> > [48]http://www.mega-nerd.com/ > <[49]http://www.mega-nerd.com/> > >> <[50]http://www.mega-nerd.com/ > <[51]http://www.mega-nerd.com/>> > >> > > >> _______________________________________________ > >> > ghc-steering-committee mailing list > >> > [52]ghc-steering-committee at haskell.org > >> > >> > > >> > > >> > > >> > >> > [56]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > <[57]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee> > <[58]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee > <[59]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee>> > >> > > >> > > _______________________________________________ > >> > ghc-steering-committee mailing list > >> > [60]ghc-steering-committee at haskell.org > >> > >> > > >> > > >> > > >> > >> > [64]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > <[65]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee> > <[66]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee > <[67]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee>> > >> > > >> > > _______________________________________________ > >> > ghc-steering-committee mailing list > >> > [68]ghc-steering-committee at haskell.org > >> > >> > >> > > >> > > >> > >> > [72]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > <[73]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee> > <[74]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee > <[75]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee>> > >> > > >> > > >> > > >> > -- > >> > Arnaud Spiwack > >> > Director, Research at [76]https://moduscreate.com > >> <[77]https://moduscreate.com> > <[78]https://moduscreate.com > >> <[79]https://moduscreate.com>> > >> > and [80]https://tweag.io <[81]https://tweag.io> > <[82]https://tweag.io > >> <[83]https://tweag.io>>. > >> > > >> > _______________________________________________ > >> > ghc-steering-committee mailing list > >> > [84]ghc-steering-committee at haskell.org > >> > >> > > >> > >> > [86]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > <[87]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee> > >> > >> -- Adam Gundry, Haskell Consultant > >> Well-Typed LLP, [88]https://www.well-typed.com/ > >> <[89]https://www.well-typed.com/> > >> > >> Registered in England & Wales, OC335890 > >> 27 Old Gloucester Street, London WC1N 3AX, England > >> > >> > <[90]https://www.google.com/maps/search/27+Old+Gloucester+Street,+Lo > ndon+WC1N+3AX,+England?entry=gmail&source=g> > >> > >> _______________________________________________ > >> ghc-steering-committee mailing list > >> [91]ghc-steering-committee at haskell.org > >> > >> > >> > [93]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > <[94]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee> > >> > >> _______________________________________________ > >> ghc-steering-committee mailing list > >> [95]ghc-steering-committee at haskell.org > >> > >> > >> > [97]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > ommittee > <[98]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee> > >> > >> > >> > >> -- Arnaud Spiwack > >> Director, Research at [99]https://moduscreate.com > >> <[100]https://moduscreate.com> and [101]https://tweag.io > <[102]https://tweag.io>. > >> _______________________________________________ > >> ghc-steering-committee mailing list > >> [103]ghc-steering-committee at haskell.org > >> > >> > >> > [105]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee > <[106]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering > -committee> > >> > >> > >> _______________________________________________ > >> ghc-steering-committee mailing list > >> [107]ghc-steering-committee at haskell.org > >> > [108]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee > > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, [109]https://www.well-typed.com/ > > Registered in England & Wales, OC335890 > 27 Old Gloucester Street, London WC1N 3AX, England > > _______________________________________________ > ghc-steering-committee mailing list > [110]ghc-steering-committee at haskell.org > [111]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee > > _______________________________________________ > ghc-steering-committee mailing list > [112]ghc-steering-committee at haskell.org > [113]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > committee > > References > > 1. mailto:ghc-steering-committee at haskell.org > 2. mailto:ghc-steering-committee at haskell.org > 3. https://github.com/ghc-proposals/ghc-proposals/pull/668 > 4. mailto:ghc-steering-committee at haskell.org > 5. mailto:ghc-steering-committee at haskell.org > 6. mailto:ghc-steering-committee at haskell.org > 7. mailto:ghc-steering-committee at haskell.org > 8. mailto:ghc-steering-committee at haskell.org > 9. mailto:ghc-steering-committee at haskell.org > 10. https://github.com/ghc-proposals/ghc-proposals/pull/668 > 11. https://github.com/ghc-proposals/ghc-proposals/pull/668 > 12. https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397 > 13. https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397 > 14. https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901 > 15. https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901 > 16. mailto:simon.peytonjones at gmail.com > 17. mailto:simon.peytonjones at gmail.com > 18. mailto:simon.peytonjones at gmail.com > 19. mailto:simon.peytonjones at gmail.com > 20. mailto:sgraf1337 at gmail.com > 21. mailto:sgraf1337 at gmail.com > 22. mailto:sgraf1337 at gmail.com > 23. mailto:sgraf1337 at gmail.com > 24. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > 25. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > 26. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > 27. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > 28. mailto:erikd at mega-nerd.com > 29. mailto:erikd at mega-nerd.com > 30. mailto:erikd at mega-nerd.com > 31. mailto:erikd at mega-nerd.com > 32. mailto:malte.ott at maralorn.de > 33. mailto:malte.ott at maralorn.de > 34. mailto:malte.ott at maralorn.de > 35. mailto:malte.ott at maralorn.de > 36. https://github.com/ghc-proposals/ghc-proposals/pull/668 > 37. https://github.com/ghc-proposals/ghc-proposals/pull/668 > 38. https://github.com/ghc-proposals/ghc-proposals/pull/668 > 39. https://github.com/ghc-proposals/ghc-proposals/pull/668 > 40. mailto:ghc-steering-committee at haskell.org > 41. mailto:ghc-steering-committee at haskell.org > 42. mailto:ghc-steering-committee at haskell.org > 43. mailto:ghc-steering-committee at haskell.org > 44. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 45. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 46. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 47. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 48. http://www.mega-nerd.com/ > 49. http://www.mega-nerd.com/ > 50. http://www.mega-nerd.com/ > 51. http://www.mega-nerd.com/ > 52. mailto:ghc-steering-committee at haskell.org > 53. mailto:ghc-steering-committee at haskell.org > 54. mailto:ghc-steering-committee at haskell.org > 55. mailto:ghc-steering-committee at haskell.org > 56. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 57. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 58. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 59. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 60. mailto:ghc-steering-committee at haskell.org > 61. mailto:ghc-steering-committee at haskell.org > 62. mailto:ghc-steering-committee at haskell.org > 63. mailto:ghc-steering-committee at haskell.org > 64. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 65. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 66. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 67. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 68. mailto:ghc-steering-committee at haskell.org > 69. mailto:ghc-steering-committee at haskell.org > 70. mailto:ghc-steering-committee at haskell.org > 71. mailto:ghc-steering-committee at haskell.org > 72. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 73. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 74. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 75. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 76. https://moduscreate.com/ > 77. https://moduscreate.com/ > 78. https://moduscreate.com/ > 79. https://moduscreate.com/ > 80. https://tweag.io/ > 81. https://tweag.io/ > 82. https://tweag.io/ > 83. https://tweag.io/ > 84. mailto:ghc-steering-committee at haskell.org > 85. mailto:ghc-steering-committee at haskell.org > 86. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 87. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 88. https://www.well-typed.com/ > 89. https://www.well-typed.com/ > 90. https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g > 91. mailto:ghc-steering-committee at haskell.org > 92. mailto:ghc-steering-committee at haskell.org > 93. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 94. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 95. mailto:ghc-steering-committee at haskell.org > 96. mailto:ghc-steering-committee at haskell.org > 97. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 98. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 99. https://moduscreate.com/ > 100. https://moduscreate.com/ > 101. https://tweag.io/ > 102. https://tweag.io/ > 103. mailto:ghc-steering-committee at haskell.org > 104. mailto:ghc-steering-committee at haskell.org > 105. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 106. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 107. mailto:ghc-steering-committee at haskell.org > 108. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 109. https://www.well-typed.com/ > 110. mailto:ghc-steering-committee at haskell.org > 111. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > 112. mailto:ghc-steering-committee at haskell.org > 113. 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 From mpg at mpg.is Thu Apr 10 06:49:14 2025 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Thu, 10 Apr 2025 08:49:14 +0200 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: I like it, but preferably with Simon’s suggested edit. /Matti Palli On Wed, Apr 9, 2025 at 17:22 Malte Ott via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > I like this very much. In favor! > > > On 9 April 2025 13:18:59 CEST, Simon Peyton Jones via > ghc-steering-committee wrote: > >> I'm in support. I have added a suggested edit. >> >> On Wed, 9 Apr 2025 at 10:34, Simon Marlow via ghc-steering-committee < >> ghc-steering-committee at haskell.org> 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 >>>> >>>> >>> _______________________________________________ >>> 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: From moritz.angermann at gmail.com Fri Apr 11 04:39:55 2025 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 11 Apr 2025 13:39:55 +0900 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: References: <82a60743-3211-48f8-9e99-db603ac4ee6c@well-typed.com> <9c24cac5-4dc8-4886-a589-750e10045a04@well-typed.com> Message-ID: I'm also in favor. On Thu, 10 Apr 2025 at 07:13, Malte Ott via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > I like this a lot. In favor! > > On 2025-04-09 10:02, Simon Peyton Jones via ghc-steering-committee wrote: > > I'm thumbs up -- but I have added a post with a list of suggested > > presentational cleanups. > > > > (Adam if you are worn out I suppose I could execute on them myself. I > > don't want to keep erecting new obstacles.) > > > > Simon > > > > On Wed, 9 Apr 2025 at 03:31, Jakob Brünker via ghc-steering-committee > > <[1]ghc-steering-committee at haskell.org> wrote: > > > > Hi, > > > > The updated proposal looks good to me! > > > > Jakob > > > > On Tue, Apr 8, 2025 at 11:00 AM Adam Gundry via ghc-steering-committee > > <[2]ghc-steering-committee at haskell.org> wrote: > > > > I have now updated this proposal on the basis of the vote: > > > > [3]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 > > >> <[4]ghc-steering-committee at haskell.org > > >> > 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 <[6] > ghc-steering-committee at haskell.org > > >> > 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 > > <[8]ghc-steering-committee at haskell.org > > >> > 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] > > [10]https://github.com/ghc-proposals/ghc-proposals/pull/668 > > >> > > <[11]https://github.com/ghc-proposals/ghc-proposals/pull/668> > > >> > > >> [1] > > >> > > >> > > [12] > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecom > > ment-2561282397 > > <[13] > https://github.com/ghc-proposals/ghc-proposals/pull/668#issueco > > mment-2561282397> > > >> > > >> [2] > > >> > > >> > > [14] > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecom > > ment-2564274901 > > <[15] > https://github.com/ghc-proposals/ghc-proposals/pull/668#issueco > > mment-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 > > >> > <[16]simon.peytonjones at gmail.com > > >> > > >> > >> >> 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 > > >> <[20]sgraf1337 at gmail.com > > > > >> > > >> >> wrote: > > >> > > > >> > I'm in support as well, but would like to > > see a > > >> single > > >> > clarifying sentence added to the proposal. > > >> > > > >> > > >> > > [24] > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussi > > on_r1826533003 > > <[25] > https://github.com/ghc-proposals/ghc-proposals/pull/668#discuss > > ion_r1826533003> > > <[26] > https://github.com/ghc-proposals/ghc-proposals/pull/668#discuss > > ion_r1826533003 > > <[27] > https://github.com/ghc-proposals/ghc-proposals/pull/668#discuss > > ion_r1826533003>> > > >> > > > >> > Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb > > Erik de > > >> Castro Lopo > > >> > <[28]erikd at mega-nerd.com > > > > >> > >>: > > >> > > > >> > > > >> > > > >> > 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 > > >> > <[32]malte.ott at maralorn.de > > >> > > > >> >> wrote: > > >> > > > > >> > > > > > >> > > > On 2024-10-29 20:12, Adam Gundry > > wrote: > > >> > > > > > > >> > > > [36]https://github.com/ghc-proposals/ghc-proposals/pull/668 > > >> > > <[37]https://github.com/ghc-proposals/ghc-proposals/pull/668> > > >> > > > >> <[38]https://github.com/ghc-proposals/ghc-proposals/pull/668 > > >> > > <[39]https://github.com/ghc-proposals/ghc-proposals/pull/668>> > > >> > > > > > >> > > > I’m in support. > > >> > > > > > >> > > > Best > > >> > > > Malte > > >> > > > > > >> _______________________________________________ > > >> > > > ghc-steering-committee mailing > > list > > >> > > > > > [40]ghc-steering-committee at haskell.org > > >> > > >> > > > > >> > > > >> > > > > > >> > > > >> > > >> > > [44] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > <[45] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee> > > <[46] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee > > <[47] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee>> > > >> > > > > > >> > > > >> > > > >> > -- > > >> > > > >> > > -------------------------------------------------------------------- > > -- > > >> > Erik de Castro Lopo > > >> > [48]http://www.mega-nerd.com/ > > <[49]http://www.mega-nerd.com/> > > >> <[50]http://www.mega-nerd.com/ > > <[51]http://www.mega-nerd.com/>> > > >> > > > >> _______________________________________________ > > >> > ghc-steering-committee mailing list > > >> > [52]ghc-steering-committee at haskell.org > > >> > > >> > > > > >> > > > >> > > > >> > > >> > > [56] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > <[57] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee> > > <[58] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee > > <[59] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee>> > > >> > > > >> > > > _______________________________________________ > > >> > ghc-steering-committee mailing list > > >> > [60]ghc-steering-committee at haskell.org > > >> > > >> > > > > >> > > > >> > > > >> > > >> > > [64] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > <[65] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee> > > <[66] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee > > <[67] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee>> > > >> > > > >> > > > _______________________________________________ > > >> > ghc-steering-committee mailing list > > >> > [68]ghc-steering-committee at haskell.org > > >> > > >> > ghc-steering-committee at haskell.org > > >> > > > >> > > > >> > > >> > > [72] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > <[73] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee> > > <[74] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee > > <[75] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee>> > > >> > > > >> > > > >> > > > >> > -- > > >> > Arnaud Spiwack > > >> > Director, Research at [76]https://moduscreate.com > > >> <[77]https://moduscreate.com> > > <[78]https://moduscreate.com > > >> <[79]https://moduscreate.com>> > > >> > and [80]https://tweag.io <[81]https://tweag.io> > > <[82]https://tweag.io > > >> <[83]https://tweag.io>>. > > >> > > > >> > _______________________________________________ > > >> > ghc-steering-committee mailing list > > >> > [84]ghc-steering-committee at haskell.org > > >> > > >> > > > >> > > >> > > [86] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > <[87] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee> > > >> > > >> -- Adam Gundry, Haskell Consultant > > >> Well-Typed LLP, [88]https://www.well-typed.com/ > > >> <[89]https://www.well-typed.com/> > > >> > > >> Registered in England & Wales, OC335890 > > >> 27 Old Gloucester Street, London WC1N 3AX, England > > >> > > >> > > <[90] > https://www.google.com/maps/search/27+Old+Gloucester+Street,+Lo > > ndon+WC1N+3AX,+England?entry=gmail&source=g> > > >> > > >> _______________________________________________ > > >> ghc-steering-committee mailing list > > >> [91]ghc-steering-committee at haskell.org > > >> > > >> > > >> > > [93] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > <[94] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee> > > >> > > >> _______________________________________________ > > >> ghc-steering-committee mailing list > > >> [95]ghc-steering-committee at haskell.org > > >> > > >> > > >> > > [97] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-c > > ommittee > > <[98] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee> > > >> > > >> > > >> > > >> -- Arnaud Spiwack > > >> Director, Research at [99]https://moduscreate.com > > >> <[100]https://moduscreate.com> and [101]https://tweag.io > > <[102]https://tweag.io>. > > >> _______________________________________________ > > >> ghc-steering-committee mailing list > > >> [103]ghc-steering-committee at haskell.org > > >> > > >> > > >> > > [105] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee > > <[106] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering > > -committee> > > >> > > >> > > >> _______________________________________________ > > >> ghc-steering-committee mailing list > > >> [107]ghc-steering-committee at haskell.org > > >> > > [108] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee > > > > > > > -- > > Adam Gundry, Haskell Consultant > > Well-Typed LLP, [109]https://www.well-typed.com/ > > > > Registered in England & Wales, OC335890 > > 27 Old Gloucester Street, London WC1N 3AX, England > > > > _______________________________________________ > > ghc-steering-committee mailing list > > [110]ghc-steering-committee at haskell.org > > [111] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee > > > > _______________________________________________ > > ghc-steering-committee mailing list > > [112]ghc-steering-committee at haskell.org > > [113] > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- > > committee > > > > References > > > > 1. mailto:ghc-steering-committee at haskell.org > > 2. mailto:ghc-steering-committee at haskell.org > > 3. https://github.com/ghc-proposals/ghc-proposals/pull/668 > > 4. mailto:ghc-steering-committee at haskell.org > > 5. mailto:ghc-steering-committee at haskell.org > > 6. mailto:ghc-steering-committee at haskell.org > > 7. mailto:ghc-steering-committee at haskell.org > > 8. mailto:ghc-steering-committee at haskell.org > > 9. mailto:ghc-steering-committee at haskell.org > > 10. https://github.com/ghc-proposals/ghc-proposals/pull/668 > > 11. https://github.com/ghc-proposals/ghc-proposals/pull/668 > > 12. > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397 > > 13. > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397 > > 14. > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901 > > 15. > https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274901 > > 16. mailto:simon.peytonjones at gmail.com > > 17. mailto:simon.peytonjones at gmail.com > > 18. mailto:simon.peytonjones at gmail.com > > 19. mailto:simon.peytonjones at gmail.com > > 20. mailto:sgraf1337 at gmail.com > > 21. mailto:sgraf1337 at gmail.com > > 22. mailto:sgraf1337 at gmail.com > > 23. mailto:sgraf1337 at gmail.com > > 24. > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > > 25. > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > > 26. > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > > 27. > https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003 > > 28. mailto:erikd at mega-nerd.com > > 29. mailto:erikd at mega-nerd.com > > 30. mailto:erikd at mega-nerd.com > > 31. mailto:erikd at mega-nerd.com > > 32. mailto:malte.ott at maralorn.de > > 33. mailto:malte.ott at maralorn.de > > 34. mailto:malte.ott at maralorn.de > > 35. mailto:malte.ott at maralorn.de > > 36. https://github.com/ghc-proposals/ghc-proposals/pull/668 > > 37. https://github.com/ghc-proposals/ghc-proposals/pull/668 > > 38. https://github.com/ghc-proposals/ghc-proposals/pull/668 > > 39. https://github.com/ghc-proposals/ghc-proposals/pull/668 > > 40. mailto:ghc-steering-committee at haskell.org > > 41. mailto:ghc-steering-committee at haskell.org > > 42. mailto:ghc-steering-committee at haskell.org > > 43. mailto:ghc-steering-committee at haskell.org > > 44. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 45. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 46. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 47. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 48. http://www.mega-nerd.com/ > > 49. http://www.mega-nerd.com/ > > 50. http://www.mega-nerd.com/ > > 51. http://www.mega-nerd.com/ > > 52. mailto:ghc-steering-committee at haskell.org > > 53. mailto:ghc-steering-committee at haskell.org > > 54. mailto:ghc-steering-committee at haskell.org > > 55. mailto:ghc-steering-committee at haskell.org > > 56. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 57. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 58. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 59. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 60. mailto:ghc-steering-committee at haskell.org > > 61. mailto:ghc-steering-committee at haskell.org > > 62. mailto:ghc-steering-committee at haskell.org > > 63. mailto:ghc-steering-committee at haskell.org > > 64. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 65. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 66. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 67. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 68. mailto:ghc-steering-committee at haskell.org > > 69. mailto:ghc-steering-committee at haskell.org > > 70. mailto:ghc-steering-committee at haskell.org > > 71. mailto:ghc-steering-committee at haskell.org > > 72. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 73. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 74. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 75. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 76. https://moduscreate.com/ > > 77. https://moduscreate.com/ > > 78. https://moduscreate.com/ > > 79. https://moduscreate.com/ > > 80. https://tweag.io/ > > 81. https://tweag.io/ > > 82. https://tweag.io/ > > 83. https://tweag.io/ > > 84. mailto:ghc-steering-committee at haskell.org > > 85. mailto:ghc-steering-committee at haskell.org > > 86. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 87. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 88. https://www.well-typed.com/ > > 89. https://www.well-typed.com/ > > 90. > https://www.google.com/maps/search/27+Old+Gloucester+Street,+London+WC1N+3AX,+England?entry=gmail&source=g > > 91. mailto:ghc-steering-committee at haskell.org > > 92. mailto:ghc-steering-committee at haskell.org > > 93. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 94. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 95. mailto:ghc-steering-committee at haskell.org > > 96. mailto:ghc-steering-committee at haskell.org > > 97. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 98. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 99. https://moduscreate.com/ > > 100. https://moduscreate.com/ > > 101. https://tweag.io/ > > 102. https://tweag.io/ > > 103. mailto:ghc-steering-committee at haskell.org > > 104. mailto:ghc-steering-committee at haskell.org > > 105. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 106. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 107. mailto:ghc-steering-committee at haskell.org > > 108. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 109. https://www.well-typed.com/ > > 110. mailto:ghc-steering-committee at haskell.org > > 111. > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee > > 112. mailto:ghc-steering-committee at haskell.org > > 113. > 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: From moritz.angermann at gmail.com Fri Apr 11 04:44:19 2025 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 11 Apr 2025 13:44:19 +0900 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: I'm on the same page as Matthias here. I'm in favour with Simons suggested edits. To me that is specifically around guiding people to insulate themselves against accidental breakage. On Thu, 10 Apr 2025 at 15:49, Matthías Páll Gissurarson via ghc-steering-committee wrote: > I like it, but preferably with Simon’s suggested edit. > > /Matti Palli > > > On Wed, Apr 9, 2025 at 17:22 Malte Ott via ghc-steering-committee < > ghc-steering-committee at haskell.org> wrote: > >> I like this very much. In favor! >> >> >> On 9 April 2025 13:18:59 CEST, Simon Peyton Jones via >> ghc-steering-committee wrote: >> >>> I'm in support. I have added a suggested edit. >>> >>> On Wed, 9 Apr 2025 at 10:34, Simon Marlow via ghc-steering-committee < >>> ghc-steering-committee at haskell.org> 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 >>>>> >>>>> >>>> _______________________________________________ >>>> 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: From mpg at mpg.is Fri Apr 11 07:50:04 2025 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Fri, 11 Apr 2025 09:50:04 +0200 Subject: [ghc-steering-committee] Please review #687: Monad of No Return In-Reply-To: <2dfa46f5-22e5-41df-9a57-472b634af233@well-typed.com> References: <2dfa46f5-22e5-41df-9a57-472b634af233@well-typed.com> Message-ID: Thank you all! This is a slightly nuanced one, so I’ll write a summary today for us to vote on. /Matti Palli On Tue, Apr 8, 2025 at 09:39 Adam Gundry via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > Dear Committee, > > Benjamin proposes to revive and move forward the Monad of No Return > proposal: > > https://github.com/ghc-proposals/ghc-proposals/pull/687 > > https://github.com/L0neGamer/ghc-proposals/blob/amending-mrp/proposals/0000-amending-mrp.rst > > I'd like to nominate Matthías as the shepherd. > > 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 > > _______________________________________________ > 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 simon.peytonjones at gmail.com Fri Apr 11 08:01:34 2025 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Fri, 11 Apr 2025 09:01:34 +0100 Subject: [ghc-steering-committee] Please review #687: Monad of No Return In-Reply-To: References: <2dfa46f5-22e5-41df-9a57-472b634af233@well-typed.com> Message-ID: Can I draw your attention to https://github.com/haskell/core-libraries-committee/issues/325#issuecomment-2796062617 ? The CLC plan to revisit the proposal, and while continued discussion here is fine, I don't think we could act until the CLC concludes. My thought: let's move this back to "under revision" rather than shepherd it to a conclusion. We (maybe Adam or Matthias?) should write to the authors to explain this. In a sympathetic and supportive way -- I think we all want to see Haskell progress towards beauty and not just keep bad warts; but it's just a tricky one. Simon On Fri, 11 Apr 2025 at 08:50, Matthías Páll Gissurarson via ghc-steering-committee wrote: > Thank you all! This is a slightly nuanced one, so I’ll write a summary > today for us to vote on. > > /Matti Palli > > > On Tue, Apr 8, 2025 at 09:39 Adam Gundry via ghc-steering-committee < > ghc-steering-committee at haskell.org> wrote: > >> Dear Committee, >> >> Benjamin proposes to revive and move forward the Monad of No Return >> proposal: >> >> https://github.com/ghc-proposals/ghc-proposals/pull/687 >> >> https://github.com/L0neGamer/ghc-proposals/blob/amending-mrp/proposals/0000-amending-mrp.rst >> >> I'd like to nominate Matthías as the shepherd. >> >> 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 >> >> _______________________________________________ >> 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: From mpg at mpg.is Fri Apr 11 20:38:38 2025 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Fri, 11 Apr 2025 22:38:38 +0200 Subject: [ghc-steering-committee] Please review #687: Monad of No Return In-Reply-To: References: <2dfa46f5-22e5-41df-9a57-472b634af233@well-typed.com> Message-ID: I agree, we should wait for the CLC before voting on this proposal. To summarize: 10 years ago, the CLC voted on the "Monad of No Return" proposal, which removes `return` and `(>>)` from `Monad`, to be replaced by `pure` and `(*>)` from `Applicative`, with `return` and `(>>)` being replaced with top-level bindings. The implementation of this was to proceed in multiple phases: + Phase 1 (implemented in 8.2, default in 9.2) that warns when `return` and `(>>)` are overwritten with non-canonical implementations (something other than `pure` and `(*>)`) + Phase 2: `return` and `(>>)` become top-level bindings and GHC ignores canonical implementation of these + Phase 3: Warn about all `return` and `(>>)` overwrites + Phase 4: Disallow overwrites of `return` and `(>>)`, removing them from Monad. This proposal proposes merging these into 2 phases: + Phase 2: Make non-canonical implementations of `(>>)` and `return` a compilation error, and add a warning for canonical ones + Phase 3: Move `return` and `(>>)` to the top-level and remove them from Monad. I'm in favor of *this specific change*, i.e. reducing the phases and easing migration. However, there are multiple concerns raised with the original MoNR proposal, as compiled by Julian: + `(*>)` is not as performant as `(>>)` in some cases, which affects a large portion of the ecosystem, as this is an "unseen default". + The impact assessment is stale, and the original motivation outdated + There are some corner cases that mean that behavior might potentially change, which is worrying So there's a question of whether we should keep going with the "Monad of No Return" proposal at all (of which this proposal is a modification), and if so, in what form we should do so. As Simon points out, the CLC is discussing this, and I agree that the time is not right for a vote at the moment. We should think about the original proposal, and I encourage you to weigh in on the [CLC discussion]( https://github.com/haskell/core-libraries-committee/issues/325) (it's "internal", but multiple observers have already chimed in) Unless anyone disagrees in the next 2 days (i.e. by Monday), I will inform the authors of this proposal of this, and suggest that we move the proposal back to "under revision" until we've gotten feedback from the CLC. On Fri, 11 Apr 2025 at 10:01, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Can I draw your attention to > https://github.com/haskell/core-libraries-committee/issues/325#issuecomment-2796062617 > ? > > The CLC plan to revisit the proposal, and while continued discussion here > is fine, I don't think we could act until the CLC concludes. My thought: > let's move this back to "under revision" rather than shepherd it to a > conclusion. > > We (maybe Adam or Matthias?) should write to the authors to explain this. > In a sympathetic and supportive way -- I think we all want to see Haskell > progress towards beauty and not just keep bad warts; but it's just a tricky > one. > > Simon > > On Fri, 11 Apr 2025 at 08:50, Matthías Páll Gissurarson via > ghc-steering-committee wrote: > >> Thank you all! This is a slightly nuanced one, so I’ll write a summary >> today for us to vote on. >> >> /Matti Palli >> >> >> On Tue, Apr 8, 2025 at 09:39 Adam Gundry via ghc-steering-committee < >> ghc-steering-committee at haskell.org> wrote: >> >>> Dear Committee, >>> >>> Benjamin proposes to revive and move forward the Monad of No Return >>> proposal: >>> >>> https://github.com/ghc-proposals/ghc-proposals/pull/687 >>> >>> https://github.com/L0neGamer/ghc-proposals/blob/amending-mrp/proposals/0000-amending-mrp.rst >>> >>> I'd like to nominate Matthías as the shepherd. >>> >>> 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 >>> >>> _______________________________________________ >>> 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 >> > -- -- Matthías Páll Gissurarson -------------- next part -------------- An HTML attachment was scrubbed... URL: From arnaud.spiwack at tweag.io Mon Apr 14 01:42:48 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Mon, 14 Apr 2025 10:42:48 +0900 Subject: [ghc-steering-committee] Please review #687: Monad of No Return In-Reply-To: References: <2dfa46f5-22e5-41df-9a57-472b634af233@well-typed.com> Message-ID: I also agree that _if_ we do the changes that the proposal wants, then the revised timeline/steps sound better than the original. On Sat, 12 Apr 2025 at 05:39, Matthías Páll Gissurarson via ghc-steering-committee wrote: > I agree, we should wait for the CLC before voting on this proposal. > > To summarize: > > 10 years ago, the CLC voted on the "Monad of No Return" proposal, which > removes `return` and `(>>)` from `Monad`, to be replaced by `pure` and > `(*>)` from `Applicative`, with `return` and `(>>)` being replaced with > top-level bindings. The implementation of this was to proceed in multiple > phases: > + Phase 1 (implemented in 8.2, default in 9.2) that warns when `return` > and `(>>)` are overwritten with non-canonical implementations (something > other than `pure` and `(*>)`) > + Phase 2: `return` and `(>>)` become top-level bindings and GHC ignores > canonical implementation of these > + Phase 3: Warn about all `return` and `(>>)` overwrites > + Phase 4: Disallow overwrites of `return` and `(>>)`, removing them from > Monad. > > This proposal proposes merging these into 2 phases: > + Phase 2: Make non-canonical implementations of `(>>)` and `return` a > compilation error, and add a warning for canonical ones > + Phase 3: Move `return` and `(>>)` to the top-level and remove them from > Monad. > > I'm in favor of *this specific change*, i.e. reducing the phases and > easing migration. > > However, there are multiple concerns raised with the original MoNR > proposal, as compiled by Julian: > + `(*>)` is not as performant as `(>>)` in some cases, which affects a > large portion of the ecosystem, as this is an "unseen default". > + The impact assessment is stale, and the original motivation outdated > + There are some corner cases that mean that behavior might potentially > change, which is worrying > > So there's a question of whether we should keep going with the "Monad of > No Return" proposal at all (of which this proposal is a modification), and > if so, in what form we should do so. > > As Simon points out, the CLC is discussing this, and I agree that the time > is not right for a vote at the moment. We should think about the original > proposal, and I encourage you to weigh in on the [CLC discussion]( > https://github.com/haskell/core-libraries-committee/issues/325) (it's > "internal", but multiple observers have already chimed in) > > Unless anyone disagrees in the next 2 days (i.e. by Monday), I will inform > the authors of this proposal of this, and suggest that we move the proposal > back to "under revision" until we've gotten feedback from the CLC. > > > On Fri, 11 Apr 2025 at 10:01, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> Can I draw your attention to >> https://github.com/haskell/core-libraries-committee/issues/325#issuecomment-2796062617 >> ? >> >> The CLC plan to revisit the proposal, and while continued discussion here >> is fine, I don't think we could act until the CLC concludes. My thought: >> let's move this back to "under revision" rather than shepherd it to a >> conclusion. >> >> We (maybe Adam or Matthias?) should write to the authors to explain >> this. In a sympathetic and supportive way -- I think we all want to see >> Haskell progress towards beauty and not just keep bad warts; but it's just >> a tricky one. >> >> Simon >> >> On Fri, 11 Apr 2025 at 08:50, Matthías Páll Gissurarson via >> ghc-steering-committee wrote: >> >>> Thank you all! This is a slightly nuanced one, so I’ll write a summary >>> today for us to vote on. >>> >>> /Matti Palli >>> >>> >>> On Tue, Apr 8, 2025 at 09:39 Adam Gundry via ghc-steering-committee < >>> ghc-steering-committee at haskell.org> wrote: >>> >>>> Dear Committee, >>>> >>>> Benjamin proposes to revive and move forward the Monad of No Return >>>> proposal: >>>> >>>> https://github.com/ghc-proposals/ghc-proposals/pull/687 >>>> >>>> https://github.com/L0neGamer/ghc-proposals/blob/amending-mrp/proposals/0000-amending-mrp.rst >>>> >>>> I'd like to nominate Matthías as the shepherd. >>>> >>>> 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 >>>> >>>> _______________________________________________ >>>> 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 >>> >> > > -- > -- Matthías Páll Gissurarson > _______________________________________________ > 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 arnaud.spiwack at tweag.io Mon Apr 14 01:44:11 2025 From: arnaud.spiwack at tweag.io (Arnaud Spiwack) Date: Mon, 14 Apr 2025 10:44:11 +0900 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: I've been quite pushy about these things, so it probably goes without saying, but anyway: I like the look of this iteration. On Fri, 11 Apr 2025 at 13:44, Moritz Angermann via ghc-steering-committee < ghc-steering-committee at haskell.org> wrote: > I'm on the same page as Matthias here. I'm in favour with Simons suggested > edits. To me that is specifically around guiding people to insulate > themselves against accidental breakage. > > On Thu, 10 Apr 2025 at 15:49, Matthías Páll Gissurarson via > ghc-steering-committee wrote: > >> I like it, but preferably with Simon’s suggested edit. >> >> /Matti Palli >> >> >> On Wed, Apr 9, 2025 at 17:22 Malte Ott via ghc-steering-committee < >> ghc-steering-committee at haskell.org> wrote: >> >>> I like this very much. In favor! >>> >>> >>> On 9 April 2025 13:18:59 CEST, Simon Peyton Jones via >>> ghc-steering-committee wrote: >>> >>>> I'm in support. I have added a suggested edit. >>>> >>>> On Wed, 9 Apr 2025 at 10:34, Simon Marlow via ghc-steering-committee < >>>> ghc-steering-committee at haskell.org> 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 >>>>>> >>>>>> >>>>> _______________________________________________ >>>>> 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 > -- Arnaud Spiwack Director, Research at https://moduscreate.com and https://tweag.io. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikd at mega-nerd.com Mon Apr 14 05:27:41 2025 From: erikd at mega-nerd.com (Erik de Castro Lopo) Date: Mon, 14 Apr 2025 15:27:41 +1000 Subject: [ghc-steering-committee] #668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept In-Reply-To: References: Message-ID: <20250414152741.3fd111de1ee5f457aafc795d@mega-nerd.com> Sebastian Graf via ghc-steering-committee wrote: > I vote B > A > C > D as well, barring resolution of a small confusion I > raised in the proposal discussion. Yep, same for me, B > A > C > D. Erik -- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/ From sgraf1337 at gmail.com Mon Apr 14 06:52:43 2025 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Mon, 14 Apr 2025 08:52:43 +0200 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: Great! I am in favour. Arnaud Spiwack via ghc-steering-committee < ghc-steering-committee at haskell.org> schrieb am Mo., 14. Apr. 2025, 03:44: > I've been quite pushy about these things, so it probably goes without > saying, but anyway: I like the look of this iteration. > > On Fri, 11 Apr 2025 at 13:44, Moritz Angermann via ghc-steering-committee < > ghc-steering-committee at haskell.org> wrote: > >> I'm on the same page as Matthias here. I'm in favour with Simons >> suggested edits. To me that is specifically around guiding people to >> insulate themselves against accidental breakage. >> >> On Thu, 10 Apr 2025 at 15:49, Matthías Páll Gissurarson via >> ghc-steering-committee wrote: >> >>> I like it, but preferably with Simon’s suggested edit. >>> >>> /Matti Palli >>> >>> >>> On Wed, Apr 9, 2025 at 17:22 Malte Ott via ghc-steering-committee < >>> ghc-steering-committee at haskell.org> wrote: >>> >>>> I like this very much. In favor! >>>> >>>> >>>> On 9 April 2025 13:18:59 CEST, Simon Peyton Jones via >>>> ghc-steering-committee wrote: >>>> >>>>> I'm in support. I have added a suggested edit. >>>>> >>>>> On Wed, 9 Apr 2025 at 10:34, Simon Marlow via ghc-steering-committee < >>>>> ghc-steering-committee at haskell.org> 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 >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> 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 >> > > > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikd at mega-nerd.com Mon Apr 14 20:33:49 2025 From: erikd at mega-nerd.com (Erik de Castro Lopo) Date: Tue, 15 Apr 2025 06:33:49 +1000 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: <20250415063349.386c23c3dbf30137eb6dd219@mega-nerd.com> I am in favor of the proposal and SPJ's suggested edits. Erik Simon Peyton Jones via ghc-steering-committee wrote: > I'm in support. I have added a suggested edit. > > On Wed, 9 Apr 2025 at 10:34, Simon Marlow via ghc-steering-committee < > ghc-steering-committee at haskell.org> 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 > >> > > _______________________________________________ > > 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/ From mpg at mpg.is Wed Apr 16 10:00:22 2025 From: mpg at mpg.is (=?UTF-8?Q?Matth=C3=ADas_P=C3=A1ll_Gissurarson?=) Date: Wed, 16 Apr 2025 12:00:22 +0200 Subject: [ghc-steering-committee] Please review #687: Monad of No Return In-Reply-To: References: <2dfa46f5-22e5-41df-9a57-472b634af233@well-typed.com> Message-ID: Since Friday, the pull request has been marked as a draft. I've informed the author that we're waiting on CLC feedback, and that we'll leave the proposal as "under revision" until then. On Mon, 14 Apr 2025 at 03:42, Arnaud Spiwack wrote: > I also agree that _if_ we do the changes that the proposal wants, then the > revised timeline/steps sound better than the original. > > On Sat, 12 Apr 2025 at 05:39, Matthías Páll Gissurarson via > ghc-steering-committee wrote: > >> I agree, we should wait for the CLC before voting on this proposal. >> >> To summarize: >> >> 10 years ago, the CLC voted on the "Monad of No Return" proposal, which >> removes `return` and `(>>)` from `Monad`, to be replaced by `pure` and >> `(*>)` from `Applicative`, with `return` and `(>>)` being replaced with >> top-level bindings. The implementation of this was to proceed in multiple >> phases: >> + Phase 1 (implemented in 8.2, default in 9.2) that warns when `return` >> and `(>>)` are overwritten with non-canonical implementations (something >> other than `pure` and `(*>)`) >> + Phase 2: `return` and `(>>)` become top-level bindings and GHC ignores >> canonical implementation of these >> + Phase 3: Warn about all `return` and `(>>)` overwrites >> + Phase 4: Disallow overwrites of `return` and `(>>)`, removing them from >> Monad. >> >> This proposal proposes merging these into 2 phases: >> + Phase 2: Make non-canonical implementations of `(>>)` and `return` a >> compilation error, and add a warning for canonical ones >> + Phase 3: Move `return` and `(>>)` to the top-level and remove them from >> Monad. >> >> I'm in favor of *this specific change*, i.e. reducing the phases and >> easing migration. >> >> However, there are multiple concerns raised with the original MoNR >> proposal, as compiled by Julian: >> + `(*>)` is not as performant as `(>>)` in some cases, which affects a >> large portion of the ecosystem, as this is an "unseen default". >> + The impact assessment is stale, and the original motivation outdated >> + There are some corner cases that mean that behavior might potentially >> change, which is worrying >> >> So there's a question of whether we should keep going with the "Monad of >> No Return" proposal at all (of which this proposal is a modification), and >> if so, in what form we should do so. >> >> As Simon points out, the CLC is discussing this, and I agree that the >> time is not right for a vote at the moment. We should think about the >> original proposal, and I encourage you to weigh in on the [CLC discussion]( >> https://github.com/haskell/core-libraries-committee/issues/325) (it's >> "internal", but multiple observers have already chimed in) >> >> Unless anyone disagrees in the next 2 days (i.e. by Monday), I will >> inform the authors of this proposal of this, and suggest that we move the >> proposal back to "under revision" until we've gotten feedback from the CLC. >> >> >> On Fri, 11 Apr 2025 at 10:01, Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> >>> Can I draw your attention to >>> https://github.com/haskell/core-libraries-committee/issues/325#issuecomment-2796062617 >>> ? >>> >>> The CLC plan to revisit the proposal, and while continued discussion >>> here is fine, I don't think we could act until the CLC concludes. My >>> thought: let's move this back to "under revision" rather than shepherd it >>> to a conclusion. >>> >>> We (maybe Adam or Matthias?) should write to the authors to explain >>> this. In a sympathetic and supportive way -- I think we all want to see >>> Haskell progress towards beauty and not just keep bad warts; but it's just >>> a tricky one. >>> >>> Simon >>> >>> On Fri, 11 Apr 2025 at 08:50, Matthías Páll Gissurarson via >>> ghc-steering-committee wrote: >>> >>>> Thank you all! This is a slightly nuanced one, so I’ll write a summary >>>> today for us to vote on. >>>> >>>> /Matti Palli >>>> >>>> >>>> On Tue, Apr 8, 2025 at 09:39 Adam Gundry via ghc-steering-committee < >>>> ghc-steering-committee at haskell.org> wrote: >>>> >>>>> Dear Committee, >>>>> >>>>> Benjamin proposes to revive and move forward the Monad of No Return >>>>> proposal: >>>>> >>>>> https://github.com/ghc-proposals/ghc-proposals/pull/687 >>>>> >>>>> https://github.com/L0neGamer/ghc-proposals/blob/amending-mrp/proposals/0000-amending-mrp.rst >>>>> >>>>> I'd like to nominate Matthías as the shepherd. >>>>> >>>>> 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 >>>>> >>>>> _______________________________________________ >>>>> 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 >>>> >>> >> >> -- >> -- Matthías Páll Gissurarson >> _______________________________________________ >> 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. > -- -- Matthías Páll Gissurarson -------------- next part -------------- An HTML attachment was scrubbed... URL: