#668: Allow reserved identifiers as fields in OverloadedRecordDot, recommendation: accept
Dear Committee, In the interests of getting things moving on proposal #668 from Matt Parsons, I'll shepherd it myself, and recommend we accept it. https://github.com/ghc-proposals/ghc-proposals/pull/668 This is a small amendment to the OverloadedRecordDot extension to allow reserved identifiers as field names. For example, this program is currently rejected with a parse error, but would be accepted: import GHC.Records x = foo.type -- parse error, "type" is a reserved identifier data T = MkT Int foo = MkT 42 instance HasField "type" T Int where getField (MkT x) = x While "type" is not a valid field name in a traditional Haskell record data type, there is nothing stopping a user defining their own instance for `HasField "type" r a`, and some users would like to do so (e.g. when using HasField to interface with a database). Attempting to use such an instance with OverloadedRecordDot runs into this parse error. However the presence of the dot syntax means there is no ambiguity in what the user means. Even if a user wrote `x.type` by accident, they are likely to get better diagnostic information if the parser accepts the program. The only issue I see is that some syntax highlighters unaware of this change may incorrectly highlight such record projections as keywords. Please indicate whether you are happy to accept this proposal. Cheers, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, https://www.well-typed.com/ Registered in England & Wales, OC335890 27 Old Gloucester Street, London WC1N 3AX, England
On 2024-10-29 20:12, Adam Gundry wrote:
I’m in support. Best Malte
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@maralorn.de> wrote:
On 2024-10-29 20:12, Adam Gundry wrote:
I’m in support.
Best Malte _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
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@maralorn.de> wrote:
On 2024-10-29 20:12, Adam Gundry wrote:
I’m in support.
Best Malte _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
-- ---------------------------------------------------------------------- Erik de Castro Lopo http://www.mega-nerd.com/
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_r18265330... Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo < erikd@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@maralorn.de> wrote:
On 2024-10-29 20:12, Adam Gundry wrote:
I’m in support.
Best Malte _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
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 <sgraf1337@gmail.com> 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_r18265330...
Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo < erikd@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@maralorn.de> wrote:
On 2024-10-29 20:12, Adam Gundry wrote:
I’m in support.
Best Malte _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
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 <simon.peytonjones@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 <sgraf1337@gmail.com> 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_r18265330...
Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo < erikd@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@maralorn.de> wrote:
On 2024-10-29 20:12, Adam Gundry wrote:
I’m in support.
Best Malte _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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.
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-2561282... [2] https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274... 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 <simon.peytonjones@gmail.com <mailto:simon.peytonjones@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 <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>> 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_r18265330... <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@mega-nerd.com <mailto:erikd@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@maralorn.de <mailto:malte.ott@maralorn.de>> wrote: > > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668> > > > > I’m in support. > > > > Best > > Malte > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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/ <http://www.mega-nerd.com/> _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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
Hi all, I'm really torn on the syntax in B. #"..." I can get behind, but ."..." feels really odd. I can see the argument for consistency though. Hence there is no clear preference between A and B to me: A = B > C > D Best, Moritz On Thu, 20 Mar 2025 at 06:49, Adam Gundry via ghc-steering-committee < ghc-steering-committee@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-2561282...
[2]
https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274...
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 <simon.peytonjones@gmail.com <mailto:simon.peytonjones@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 <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>> 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_r18265330... < https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330...
Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo <erikd@mega-nerd.com <mailto:erikd@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@maralorn.de <mailto:malte.ott@maralorn.de>>
wrote:
> > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668> > > > > I’m in support. > > > > Best > > Malte > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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/ <http://www.mega-nerd.com/> _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
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@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-2561282...
[2]
https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274...
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 <simon.peytonjones@gmail.com <mailto:simon.peytonjones@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 <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>> 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_r18265330... < https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330...
Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo <erikd@mega-nerd.com <mailto:erikd@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@maralorn.de <mailto:malte.ott@maralorn.de>>
wrote:
> > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668> > > > > I’m in support. > > > > Best > > Malte > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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/ <http://www.mega-nerd.com/> _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://moduscreate.com> and https://tweag.io <https://tweag.io>.
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
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@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@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-2561282...
[2]
https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274...
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 <simon.peytonjones@gmail.com <mailto:simon.peytonjones@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 <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>> 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_r18265330... < https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330...
Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo <erikd@mega-nerd.com <mailto:erikd@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@maralorn.de <mailto:malte.ott@maralorn.de>>
wrote:
> > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668> > > > > I’m in support. > > > > Best > > Malte > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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/ <http://www.mega-nerd.com/> _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://moduscreate.com>
and https://tweag.io <https://tweag.io>.
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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.
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@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@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@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-2561282...
[2]
https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274...
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 <simon.peytonjones@gmail.com <mailto:simon.peytonjones@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 <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>> 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_r18265330... < https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330...
Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo <erikd@mega-nerd.com <mailto:erikd@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@maralorn.de <mailto:malte.ott@maralorn.de>>
wrote:
> > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668> > > > > I’m in support. > > > > Best > > Malte > > _______________________________________________ > > ghc-steering-committee mailing list > > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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/ <http://www.mega-nerd.com/> _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://moduscreate.com>
and https://tweag.io <https://tweag.io>.
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
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 <ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://github.com/ghc-proposals/ghc-proposals/pull/668>
[1] https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282... <https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397>
[2] https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274... <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 > <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com> <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@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 <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com> > <mailto:sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>>> 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_r18265330... <https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003> <https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... <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@mega-nerd.com <mailto:erikd@mega-nerd.com> <mailto:erikd@mega-nerd.com <mailto:erikd@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@maralorn.de <mailto:malte.ott@maralorn.de> <mailto:malte.ott@maralorn.de <mailto:malte.ott@maralorn.de>>> wrote: > > > > > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668> > <https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668>> > > > > > > I’m in support. > > > > > > Best > > > Malte > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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/ <http://www.mega-nerd.com/> <http://www.mega-nerd.com/ <http://www.mega-nerd.com/>> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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 <https://moduscreate.com> <https://moduscreate.com <https://moduscreate.com>> > and https://tweag.io <https://tweag.io> <https://tweag.io <https://tweag.io>>. > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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/ <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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://moduscreate.com> and https://tweag.io <https://tweag.io>. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@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
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 <ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://github.com/ghc-proposals/ghc-proposals/pull/668>
[1]
https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282... <https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397>
[2]
https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274... <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 > <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com> <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@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 <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com> > <mailto:sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>>> 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_r18265330... <https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003> <https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... <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@mega-nerd.com <mailto:erikd@mega-nerd.com> <mailto:erikd@mega-nerd.com <mailto:erikd@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@maralorn.de <mailto:malte.ott@maralorn.de> <mailto:malte.ott@maralorn.de <mailto:malte.ott@maralorn.de>>> wrote: > > > > > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668> > <https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668>> > > > > > > I’m in support. > > > > > > Best > > > Malte > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > > > >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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/ <http://www.mega-nerd.com/> <http://www.mega-nerd.com/ <http://www.mega-nerd.com/>> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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 <https://moduscreate.com> <https://moduscreate.com <https://moduscreate.com>> > and https://tweag.io <https://tweag.io> <https://tweag.io <https://tweag.io>>. > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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/ <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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://moduscreate.com> and https://tweag.io <https://tweag.io>. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@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
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@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 <ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://github.com/ghc-proposals/ghc-proposals/pull/668>
[1]
https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282... < https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282...
[2]
https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274... < https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274...
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 > <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com> <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@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 <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com> > <mailto:sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>>> 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_r18265330... < https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003> < https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... < https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330...
> > Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik de Castro Lopo > <erikd@mega-nerd.com <mailto:erikd@mega-nerd.com
<mailto:erikd@mega-nerd.com <mailto:erikd@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@maralorn.de <mailto:malte.ott@maralorn.de> <mailto:
malte.ott@maralorn.de
<mailto:malte.ott@maralorn.de>>> wrote: > > > > > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668> > <https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668>> > > > > > > I’m in support. > > > > > > Best > > > Malte > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > > > >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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/ <http://www.mega-nerd.com/> <http://www.mega-nerd.com/ <http://www.mega-nerd.com/>> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee < https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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 <https://moduscreate.com> <https://moduscreate.com <https://moduscreate.com>> > and https://tweag.io <https://tweag.io> <
<https://tweag.io>>. > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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/ <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...
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://moduscreate.com> and https://tweag.io <https://tweag.io>. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
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@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@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 <ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://github.com/ghc-proposals/ghc-proposals/pull/668>
[1]
https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282... < https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282...
[2]
https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274... < https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274...
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 > <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com> <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@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 <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com> > <mailto:sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>>> 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_r18265330... < https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003> < https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... < https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330...
> > Am Sa., 2. Nov. 2024 um 07:29 Uhr schrieb Erik
de
Castro Lopo > <erikd@mega-nerd.com <mailto:
erikd@mega-nerd.com>
<mailto:erikd@mega-nerd.com <mailto:erikd@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@maralorn.de <mailto:malte.ott@maralorn.de> <mailto:
malte.ott@maralorn.de
<mailto:malte.ott@maralorn.de>>> wrote: > > > > > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668> > <https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668>> > > > > > > I’m in support. > > > > > > Best > > > Malte > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > > > >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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/ <http://www.mega-nerd.com/> <http://www.mega-nerd.com/ <http://www.mega-nerd.com/>> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> >
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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 <https://moduscreate.com> <https://moduscreate.com <https://moduscreate.com>> > and https://tweag.io <https://tweag.io> <
<https://tweag.io>>. > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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/ <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...
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://moduscreate.com> and https://tweag.io <https://tweag.io>. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
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@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@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@haskell.org >> <mailto:[5]ghc-steering-committee@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@haskell.org >> <mailto:[7]ghc-steering-committee@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@haskell.org >> <mailto:[9]ghc-steering-committee@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@gmail.com >> <mailto:[17]simon.peytonjones@gmail.com> >> <mailto:[18]simon.peytonjones@gmail.com >> <mailto:[19]simon.peytonjones@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@gmail.com <mailto:[21]sgraf1337@gmail.com> >> > <mailto:[22]sgraf1337@gmail.com >> <mailto:[23]sgraf1337@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@mega-nerd.com <mailto:[29]erikd@mega-nerd.com> >> <mailto:[30]erikd@mega-nerd.com <mailto:[31]erikd@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@maralorn.de >> <mailto:[33]malte.ott@maralorn.de> <mailto:[34]malte.ott@maralorn.de >> <mailto:[35]malte.ott@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@haskell.org >> <mailto:[41]ghc-steering-committee@haskell.org> >> > <mailto:[42]ghc-steering-committee@haskell.org >> <mailto:[43]ghc-steering-committee@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@haskell.org >> <mailto:[53]ghc-steering-committee@haskell.org> >> > <mailto:[54]ghc-steering-committee@haskell.org >> <mailto:[55]ghc-steering-committee@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@haskell.org >> <mailto:[61]ghc-steering-committee@haskell.org> >> > <mailto:[62]ghc-steering-committee@haskell.org >> <mailto:[63]ghc-steering-committee@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@haskell.org >> <mailto:[69]ghc-steering-committee@haskell.org> >> > <mailto:[70]ghc-steering-committee@haskell.org >> <mailto:[71]ghc-steering-committee@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@haskell.org >> <mailto:[85]ghc-steering-committee@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@haskell.org >> <mailto:[92]ghc-steering-committee@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@haskell.org >> <mailto:[96]ghc-steering-committee@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@haskell.org >> <mailto:[104]ghc-steering-committee@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@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@haskell.org [111]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- committee
_______________________________________________ ghc-steering-committee mailing list [112]ghc-steering-committee@haskell.org [113]https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- committee
References
1. mailto:ghc-steering-committee@haskell.org 2. mailto:ghc-steering-committee@haskell.org 3. https://github.com/ghc-proposals/ghc-proposals/pull/668 4. mailto:ghc-steering-committee@haskell.org 5. mailto:ghc-steering-committee@haskell.org 6. mailto:ghc-steering-committee@haskell.org 7. mailto:ghc-steering-committee@haskell.org 8. mailto:ghc-steering-committee@haskell.org 9. mailto:ghc-steering-committee@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-2561282... 13. https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282... 14. https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274... 15. https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274... 16. mailto:simon.peytonjones@gmail.com 17. mailto:simon.peytonjones@gmail.com 18. mailto:simon.peytonjones@gmail.com 19. mailto:simon.peytonjones@gmail.com 20. mailto:sgraf1337@gmail.com 21. mailto:sgraf1337@gmail.com 22. mailto:sgraf1337@gmail.com 23. mailto:sgraf1337@gmail.com 24. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... 25. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... 26. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... 27. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... 28. mailto:erikd@mega-nerd.com 29. mailto:erikd@mega-nerd.com 30. mailto:erikd@mega-nerd.com 31. mailto:erikd@mega-nerd.com 32. mailto:malte.ott@maralorn.de 33. mailto:malte.ott@maralorn.de 34. mailto:malte.ott@maralorn.de 35. mailto:malte.ott@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@haskell.org 41. mailto:ghc-steering-committee@haskell.org 42. mailto:ghc-steering-committee@haskell.org 43. mailto:ghc-steering-committee@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@haskell.org 53. mailto:ghc-steering-committee@haskell.org 54. mailto:ghc-steering-committee@haskell.org 55. mailto:ghc-steering-committee@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@haskell.org 61. mailto:ghc-steering-committee@haskell.org 62. mailto:ghc-steering-committee@haskell.org 63. mailto:ghc-steering-committee@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@haskell.org 69. mailto:ghc-steering-committee@haskell.org 70. mailto:ghc-steering-committee@haskell.org 71. mailto:ghc-steering-committee@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@haskell.org 85. mailto:ghc-steering-committee@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... 91. mailto:ghc-steering-committee@haskell.org 92. mailto:ghc-steering-committee@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@haskell.org 96. mailto:ghc-steering-committee@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@haskell.org 104. mailto:ghc-steering-committee@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@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@haskell.org 111. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 112. mailto:ghc-steering-committee@haskell.org 113. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
I'm also in favor. On Thu, 10 Apr 2025 at 07:13, Malte Ott via ghc-steering-committee < ghc-steering-committee@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@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@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@haskell.org >> <mailto:[5]ghc-steering-committee@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@haskell.org >> <mailto:[7]ghc-steering-committee@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@haskell.org >> <mailto:[9]ghc-steering-committee@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@gmail.com >> <mailto:[17]simon.peytonjones@gmail.com> >> <mailto:[18]simon.peytonjones@gmail.com >> <mailto:[19]simon.peytonjones@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@gmail.com <mailto:[21]sgraf1337@gmail.com> >> > <mailto:[22]sgraf1337@gmail.com >> <mailto:[23]sgraf1337@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@mega-nerd.com <mailto:[29]erikd@mega-nerd.com> >> <mailto:[30]erikd@mega-nerd.com <mailto:[31]erikd@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@maralorn.de >> <mailto:[33]malte.ott@maralorn.de> <mailto:[34]malte.ott@maralorn.de >> <mailto:[35]malte.ott@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@haskell.org >> <mailto:[41]ghc-steering-committee@haskell.org> >> > <mailto:[42]ghc-steering-committee@haskell.org >> <mailto:[43]ghc-steering-committee@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@haskell.org >> <mailto:[53]ghc-steering-committee@haskell.org> >> > <mailto:[54]ghc-steering-committee@haskell.org >> <mailto:[55]ghc-steering-committee@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@haskell.org >> <mailto:[61]ghc-steering-committee@haskell.org> >> > <mailto:[62]ghc-steering-committee@haskell.org >> <mailto:[63]ghc-steering-committee@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@haskell.org >> <mailto:[69]ghc-steering-committee@haskell.org> >> > <mailto:[70] ghc-steering-committee@haskell.org >> <mailto:[71]ghc-steering-committee@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@haskell.org >> <mailto:[85]ghc-steering-committee@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@haskell.org >> <mailto:[92]ghc-steering-committee@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@haskell.org >> <mailto:[96]ghc-steering-committee@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@haskell.org >> <mailto:[104]ghc-steering-committee@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@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@haskell.org [111] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- committee
_______________________________________________ ghc-steering-committee mailing list [112]ghc-steering-committee@haskell.org [113] https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering- committee
References
1. mailto:ghc-steering-committee@haskell.org 2. mailto:ghc-steering-committee@haskell.org 3. https://github.com/ghc-proposals/ghc-proposals/pull/668 4. mailto:ghc-steering-committee@haskell.org 5. mailto:ghc-steering-committee@haskell.org 6. mailto:ghc-steering-committee@haskell.org 7. mailto:ghc-steering-committee@haskell.org 8. mailto:ghc-steering-committee@haskell.org 9. mailto:ghc-steering-committee@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-2561282... 13. https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282... 14. https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274... 15. https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274... 16. mailto:simon.peytonjones@gmail.com 17. mailto:simon.peytonjones@gmail.com 18. mailto:simon.peytonjones@gmail.com 19. mailto:simon.peytonjones@gmail.com 20. mailto:sgraf1337@gmail.com 21. mailto:sgraf1337@gmail.com 22. mailto:sgraf1337@gmail.com 23. mailto:sgraf1337@gmail.com 24. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... 25. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... 26. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... 27. https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... 28. mailto:erikd@mega-nerd.com 29. mailto:erikd@mega-nerd.com 30. mailto:erikd@mega-nerd.com 31. mailto:erikd@mega-nerd.com 32. mailto:malte.ott@maralorn.de 33. mailto:malte.ott@maralorn.de 34. mailto:malte.ott@maralorn.de 35. mailto:malte.ott@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@haskell.org 41. mailto:ghc-steering-committee@haskell.org 42. mailto:ghc-steering-committee@haskell.org 43. mailto:ghc-steering-committee@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@haskell.org 53. mailto:ghc-steering-committee@haskell.org 54. mailto:ghc-steering-committee@haskell.org 55. mailto:ghc-steering-committee@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@haskell.org 61. mailto:ghc-steering-committee@haskell.org 62. mailto:ghc-steering-committee@haskell.org 63. mailto:ghc-steering-committee@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@haskell.org 69. mailto:ghc-steering-committee@haskell.org 70. mailto:ghc-steering-committee@haskell.org 71. mailto:ghc-steering-committee@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@haskell.org 85. mailto:ghc-steering-committee@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... 91. mailto:ghc-steering-committee@haskell.org 92. mailto:ghc-steering-committee@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@haskell.org 96. mailto:ghc-steering-committee@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@haskell.org 104. mailto:ghc-steering-committee@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@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@haskell.org 111. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee 112. mailto:ghc-steering-committee@haskell.org 113. https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
Hi everyone, After a few rounds of editing to improve the spec, Simon has declared himself satisfied with #668. It now generalises OverloadedRecordDot and OverloadedRecordUpdate to support arbitrary field labels (consistent with OverloadedLabels) and does some general tidying up of the spec: https://github.com/ghc-proposals/ghc-proposals/pull/668 https://github.com/parsonsmatt/ghc-proposals/blob/patch-1/proposals/0282-rec... I believe there were no other concerns, so unless anyone objects I plan to declare this accepted in a week or so. Cheers, Adam On 08/04/2025 10:00, Adam Gundry via ghc-steering-committee wrote:
I have now updated this proposal on the basis of the vote:
https://github.com/ghc-proposals/ghc-proposals/pull/668
Please take a look and let me know if you are happy with the current state of the PR, or have any remaining concerns.
Thanks,
Adam
P.S. I will be away on holiday over the next couple of weeks, so apologies in advance for any delays in response.
On 07/04/2025 16:21, Adam Gundry via ghc-steering-committee wrote:
Thanks everyone for your responses to this. There seems to be a fairly clear consensus that the preferred option is B. (5 votes have B in first place, then 3 others either rate A and B equally or weakly prefer A to B.) Thus I plan to revise the proposal accordingly.
Adam
On 02/04/2025 10:26, Matthías Páll Gissurarson via ghc-steering-committee wrote:
I have a slight preference for B over A. The point that [2] brings up is a good one, it seems better to allow row.“foo bar”, especially when reading CSV or JSON as they mention.
So my preference is B>A>C>D
/Matti Palli
On Wed, Apr 2, 2025 at 07:56 Arnaud Spiwack via ghc-steering-committee <ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://github.com/ghc-proposals/ghc-proposals/pull/668>
[1] https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282... <https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2561282397>
[2] https://github.com/ghc-proposals/ghc-proposals/pull/668#issuecomment-2564274... <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 > <simon.peytonjones@gmail.com <mailto:simon.peytonjones@gmail.com> <mailto:simon.peytonjones@gmail.com <mailto:simon.peytonjones@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 <sgraf1337@gmail.com <mailto:sgraf1337@gmail.com> > <mailto:sgraf1337@gmail.com <mailto:sgraf1337@gmail.com>>> 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_r18265330... <https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r1826533003> <https://github.com/ghc-proposals/ghc-proposals/pull/668#discussion_r18265330... <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@mega-nerd.com <mailto:erikd@mega-nerd.com> <mailto:erikd@mega-nerd.com <mailto:erikd@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@maralorn.de <mailto:malte.ott@maralorn.de> <mailto:malte.ott@maralorn.de <mailto:malte.ott@maralorn.de>>> wrote: > > > > > > > > On 2024-10-29 20:12, Adam Gundry wrote: > > > > > https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668> > <https://github.com/ghc-proposals/ghc-proposals/pull/668 <https://github.com/ghc-proposals/ghc-proposals/pull/668>> > > > > > > I’m in support. > > > > > > Best > > > Malte > > > _______________________________________________ > > > ghc-steering-committee mailing list > > > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > > > > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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/ <http://www.mega-nerd.com/> <http://www.mega-nerd.com/ <http://www.mega-nerd.com/>> > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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@haskell.org <mailto:ghc-steering-committee@haskell.org> > <mailto:ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@haskell.org>> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee <https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee> <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 <https://moduscreate.com> <https://moduscreate.com <https://moduscreate.com>> > and https://tweag.io <https://tweag.io> <https://tweag.io <https://tweag.io>>. > > _______________________________________________ > ghc-steering-committee mailing list > ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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/ <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@haskell.org <mailto:ghc-steering-committee@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@haskell.org <mailto:ghc-steering-committee@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 <https://moduscreate.com> and https://tweag.io <https://tweag.io>. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org <mailto:ghc-steering-committee@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@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
participants (10)
-
Adam Gundry -
Arnaud Spiwack -
Erik de Castro Lopo -
Jakob Brünker -
Malte Ott -
Matthías Páll Gissurarson -
Moritz Angermann -
Sebastian Graf -
Simon Marlow -
Simon Peyton Jones